#No error handling

1 messages · Page 1 of 1 (latest)

spare prism
#

Looks good (I just like the format tbf) but having the callback literally just be for success is a bit weird imo

#

Means you’ll have to implement a timeout etc. For databases specifically (or anything that relies on an external connection) there should be a way to handle errors without having to just wait for a lack of response

#

Even if it’s just having the first argument of the callback be a success state

maiden knot
#

just given an error to be able to just fix the query, no?

spare prism
#

If im doing a database action like updating a score etc I want to know when that fails

#

Even if it’s just for the purpose of showing a popup for the user etc

maiden knot
#

under what condition would something like that fail?

spare prism
#

Connection failure

maiden knot
#

that has nothing to do with the queries, no?

spare prism
#

No, but it’s still a failure

#

It’s like HTTP. It can only really fail if the URL is malformed or for a connection error, but it’s still useful to have

maiden knot
#

i agree, what would you prefer I change?

quasi pier
#

The websocket has to be connected. If it’s not used for a period of time, it doesn’t have a heart beat, it will close the socket.

#

There’s usually a ping going in the background to keep it open

maiden knot
maiden knot
quasi pier
#

Yeah that’s how all majority of web socket packages lol

#

I think it’s a diff callback

spare prism
#

I didn’t mean OnConnect, but a callback in there to receive an initial connection failure would be good

maiden knot
#

not sure how mysqloo works internally, haven't looked into it, but I don't think this is an existing issue with mysqloo?

spare prism
#

I just mean Query should either have a separate optional error callback, or should have the first callback argument be a success state

quasi pier
#

Nah, it’s how programming works. Socket needs to be alive for the connection to take.

#

There’s another callback lemme get it

maiden knot
quasi pier
#

Query.onError( q, err, sql )
-- Called when the query errors, [String] err is the error and [String] sql is the SQL query that caused it.

Query.onSuccess( q, data )
-- Called when the query is successful, [Table] data is the data the query returned.

#

Try the generic error thing

#

See what comes up

spare prism
quasi pier
#

Threads are async, so think about one big ass straw

spare prism
#

Having it directly in the query callback would make it easier to do inline handling I mean

quasi pier
#

It can’t go sideways, so eventually these callbacks are required. You could filter the error message by key term.

#

Should show when the connection doesn’t work. Pretty sure.

#

After the initial timeout

spare prism
#

That’d be for more global error handling though right

maiden knot
quasi pier
#

Yes

#

Should include all errors

#

That SQL passes as a error

spare prism
#

Also

quasi pier
#

Cuz all it is in C++ is a try and catch setup

spare prism
#

Heartbeat pings ^^

quasi pier
#

Any websocket requires it, otherwise made to do anything but will have soft locked sockets.

spare prism
#

Yup

quasi pier
#

They’re made to be destroyed and created quickly

spare prism
#

Tbf though it’s not unreasonable to assume that the module might’ve implemented heartbeats directly since it’s such a core requirement

quasi pier
#

Exactly

#

I made the wrappers in different languages a few times over bro

#

C#, Java, PHP, Python, C++ oh boy

spare prism
quasi pier
#

Lua

spare prism
#

Without looking at it I would’ve assumed the database module would handle its own keep alive

#

Most do in other languages

quasi pier
#

Should! And would usually using something called SignalR

spare prism
#

Isn’t signalR just a websocket with extra stuff ontop

quasi pier
#

Websockets are UDP trusted and TCP exchanged

#

Yeah, I usually make my own but some people use the open source models.

#

Custom websockets are OP

#

I’d review the source code, but I have pressing stuff to do first.

spare prism