Which errors does discord.js handle and which does it let bubble up?
To give one example, it looks like discord.js handles
NotAuthenticated and unexpected close codes but not DisallowedIntents. But I wouldn't have known that if I didn't dig through the source code. And that's just websocket close codes, what about REST errors or errors that come from discord but aren't explicitly part of the API (e.g. codes like 1001)? Is there proper documentation on this anywhere?52 Replies
- What's your exact discord.js
npm list discord.js and node node -v version?
- Not a discord.js issue? Check out #other-js-ts.
- Consider reading #how-to-get-help to improve your question!
- Explain what exactly your issue is.
- Post the full error stack trace, not just the top part!
- Show your code!
- Issue solved? Press the button!in terms of ws close codes, I imagine djs will handle any reconnectable close codes for you and emits
error for non-reconnectable ones (with unexpected close codes being considered reconnectable by default)
you could of course parse the debug event if you really wanted to detect those
I believe rate limits are the only rest errors djs handles for you, but I'm not totally sure on that
furthermore this behavior can be controlled from the client's rest options
and to address something from your previous messages, I'd just like to clarify
op codes aren't error codes
I can at least understand your considering close codes to be error codes, but op codes shouldn't be considered errors
furthermore the aforementioned "Invalid session" is documented to be a sign for your bot to reconnect, so it falls under "handled reconnect" as aboveIt looks like discord.js emits the error event for any and all zlib errors, are there any that would be encountered during normal bot runtime (e.g. corrupted payload?)
those errors don't seem like something that would indicate a non-reconnectable error nor an error caused by an issue on the bot's side?
encountered as a user or by the library?
as a library user, if that's what you're asking about?
djs will handle lower level stuff for you, ypu don't need to do anything
but it emits all zlib errors untouched?
so that seems like it makes those a me problem
or am i reading the source code wrong on that
why would that make it a problem for you?
well if the errors bubble up to me then I'm expected to handle them no?
do i just ignore error events that the library emits?
that sounds like a terrible idea
you can ignore them safely, fatal errors destroy the connection
fatal as in, can't recover, not counting reconnections
so the error event emits for things that can be entirely ignored without consequence? that seems odd... shouldn't it emit a warning instead?
that doesn't sound like what an error is
also if a zlib error is thrown doesn't that usually mean a payload was lost?
the library is mostly tailored for simplicity, so complex things like the comnection part aren't meant to be handled by most users
I can't really elaborate as I'm outside home, hopefully someone else can
then why are those errors emitted for users to see?
if it's not meant to be handled by the user shouldn't the library handle it silently?
you can't recover from those events automatically though
dissallowed intents, required sharding, invalid intents... , they all require manual intervention
do zlib errors require manual intervention? they're emitted on the same error event as all of those?
also to go back to the end of this, would 1001 ws errors be handled as an unexpected close code? I'm thinking that's the case now so that would explain that part.
Which leaves me thinking the only errors I would ever have to handle (excluding user error like disallowedintents) from the ws side would be zlib errors?
technically from looking at the code yeah, but in practice I've never seen someone with a zlib error here
I've had zlib errors before, they aren't common but they happen enough to be worth handling
where? in djs?
eris, but that was years ago admittedly
and it uses the same zlib library as djs
and connects to the same websockets gateway
if my memory is right when a network packet happens to be corrupted it would throw an error at the zlib stage, because that's the first thing that would fail?
which doesn't happen often but does happen
if you search "zlib" here you'll find either people trying to build djs or on how to use it, the only error I can find is this at most <#1277706415863107595>
that channel isn't visible to me
it is
it's on this same channel (a thread)
ah it just said #unknown so i assumed
I'm unsure how eris' ws works because it seems to handle almost everything in the Client.js so it's kinda messy
i don't know how it works now but back then it was pretty much the same thing
I have never seen someone with a djs zlib error, djs even has its own ws library as a separate thing
it even supports native zlib
which eris doesn't seem to
well ignoring how often it happens, the fact is that it's possible and an error event would be emitted remains right?
or at the very least the reason that error handling exists is the same reason I'd use to justify handling it as well
I'm not sure I understand why you asked this, how is it relevant?
that was the goal of this forum question yes
as explicitly stated at the start
well I wouldn't say that necessarily, but i would like to know what errors can reach me and why
I don't think that's an unreasonable thing to desire
lol believe me I know, I wouldn't touch java unless paid to
millions? I have four so far
and every package? I'm only looking at two
you're massively exaggerating things by many orders of magnitude
is my point
and I want to handle the rest
well in the case of a zlib error I would retry
random ws code is handled internally by djs so i never need to care
and disallowed intents is a fatal error that should never occur in production
see the fact that i can answer your question so easily is exactly what I'm looking for
don't need to
I call a function, await it, it throws a zlib error, so i call it again
or well it's probably not quite that simple
actually would want to know what happens cuz it seems like it just emits an error event and carries on? returns
null?
I'm not sure why you expect me to treat those differently? although ones indicating an internet outage on my end actually should be handled a little differently
ah i see what you mean now, well in this case I want to know which errors reach me and why so i know how to react to them
for example zlib errors, i need to figure out how the actual promise is resolved when those happen since it seems like the error event being emitted is a separate thing
if an error is recoverable (e.g. 5xx, aborterror, connection reset by peer, etc) then I shouldn't just toss it into the same catch should I?
or something that isn't recoverable like a user error on my part
because I make mistakes and bugs will appear in my code. so the error handling needs to account for that too
or for example errors that indicate my internet connection has dropped, those shouldn't be put into either the fatal errors nor the regular retry category. they are recoverable and regular retrying might just spam requests needlessly.
so for those i would want to pause things until the internet outage is resolved
and instead of spending months of time letting the bot run and slowly building up a better error handling setup as errors pop up i find it easier to ask questions and figure out what I can from the startand what we're saying is that you don't need to, because it won't happen in practice
stuff that is recoverable is handled by d.js stuff that isn't, well, isn't
if I give up and say I just want to do this, not that I don't think it's worthwhile but because I don't think it's worth the time trying to convince you of it, would that get this post back to being productive?
or do you not help people with things you personally don't consider absolutely necessary?
giving help isn't necessarily about giving you what you want, but about what you need and it's more reasonable
we tend to consider that people will take the path that's more reasonable or less unnecessarily complex
if you really want to take that path you'll have to wait for some of the maintainers who was worked on zlib personally
I guess it feels like the help I've received here so far has mostly been people trying to justify not helping me and very little actual help
like a 95-5 ratio
because it's unnecessarily complex
even for unrelated simple questions I have to argue over why my question is worth answering and it's been very frustrating to be frank
I ended up finding the answer myself by digging through the source code but it was an easy question to answer.
well this line seems a bit obnoxious
they put the error code in the error message?
(this is discord.js source code, so not something you'd ask a zlib maintainer about)
looks like that's an integer, probably from here?
oh so that code is outright bugged, that's nice to see
because the error numbers are negative, which get converted into
true
i guess it makes sense when you said you've never heard of someone getting a zlib error here that the code would have mistakes that weren't found? or I'm reading it wrong which is also very possibleUnknown User•2mo ago
Message Not Public
Sign In & Join Server To View
what brought you here was thinking that you need to handle connection errors, such as zlib, to which we have replied that no, you don't need to
I didn't say you'd ask a zlib maintainer, but one of the djs maintainers, who was worked on zlib
not every maintainer has
even the npm package example code uses
< 0 instead of an implicit conversion to a boolean
and it also depends on which zlib implementation you want
so the list is even narrower
ahhh that makes a lot more sense
right now I'm mostly interested in figuring out how to tell that an error is from zlib
because that's all i truly need to know, i don't need to understand how zlib works or every individual error that can occur
too many ignored errors like that would cause consequences that wouldn't be possible to ignore in production
To cite the official nodejs docs:
yeah, I'm not saying it doesn't happen
I'm saying that if it were frequent enough as you were saying, that'd be noticed easily
djs has big bots using zlib compression
oh I thought you were saying that if it was actually bugged it would've been caught by now
you're free to make a pr to fix that, and in the meantime you could also expose the information you want
yea the question becomes the best way to do that though
obviously put the code in
error.code but that alone doesn't make it clear that an error is from zlib, it's just an integer?
add a "ZLIB" prefix to the message instead of the error code being a prefix like it is now? idkmaybe the fact that it's negative would help
you'll have to wait for a maintainter if you want a more concise answer though
yea
or maybe open a thread on #developing-djs
It's also very annoying how bad nodejs docs on zlib are
would like to know more than the class name and a four word description...
because there's zero documentation on the errors thrown by the nodejs zlib package either
had to find out on stackoverflow that it should look like this
I guess actually should really go with that for the error
make the errors as similar as possible between the two
or actually I was wrong about the code being bugged (although it probably shouldn't treat
Z_NEED_DICT the same?), my mind is frazzled after all of this. but the error being very lackluster is still true
and the issue i saw originally where it continues after finding an error is still there actually