-
-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unhandled error on close #2523
Comments
Handle the error event of your client. EDIT: If this is in a VoiceConnection, you should listen to |
Yes that would fix it. But am i wrong thinking this should be handled within the event? |
Absolutely. Errors should always be handled by the user, we are emitting them (the errors) to the So we just emit the errors to those events, you handle them, and with that, we let you do whatever you want with them. |
Thanks for the explanation @kyranet. Perhaps error handling should be made more clear in the docs, as the getting started guide doesn't mention it at all, though it is a crucial part of development. Especially in this case as disconnects are common even in production environments. It is a good idea for JavaScript libraries to include a link to error handling on their front page or toolbar somewhere. A great example is Express on the toolbar under "Guide". |
|
Based on this issue discordjs/discord.js#2523 without error handler the bot will just crash on error.
This should certainly be in "getting started" guide as it is only one extra line and honestly why would anyone want their bot to crash on what is generally a hard-to-reproduce problem (and good luck guessing what it was if you didn't have a stacktrace the first time it happened). |
Yes/No. This is depending on how far we want to go in teaching people how "node.js" works. Because this has nothing to do with us at all. This is a basic concept in event driven programming in node.js Edit: |
This comment has been minimized.
This comment has been minimized.
If you have an issue with Node's error handling system, you're more than welcome to take it up with them. Async stack traces are an ongoing issue with Node error reporting, so I don't think you'll be breaking any new ground here. The error event is intended as a way to report errors that occur during internal processes, such as a connection reset. There is no other way to report them, since they do not arise as a result of an end user action. Despite being generated by an internal mechanism, it is not the library's place to assume how you would prefer to handle such errors (logging, reporting, crashing, etc.) and so we pass it back to the end user. This is idiomatic in the Node ecosystem, as you can see in the docs. If you elect not to handle such errors, it is reasonable that the process should exit just like any other unhandled rejection. Edit: original comment deleted |
While @appellation brings up some good points concerning the nature of error handing in Node.js, it is not always reasonable for the default handler of an error to exit the process. When an error is common and its solution is clear it would be reasonable and even expected for it to be handled in a default handler set by the library. Of course you could then always change the behavior explicitly by simply setting your own handler. |
The author of the comment that I was originally replying to deleted his comment here and re-posted it in #2879. I recommend continuing this discussion there. |
My gripe was not for Node's error handling, but lack of clarity in the doc - all it says is "Emitted whenever the client's WebSocket encounters a connection error". Given that the library handles heartbeats and reconnection loop (as per doc), it is hard to tell whether the library is going to forward all errors or not even if they are handled accordingly already. I'd go as far as saying that |
Again, this relates back to teaching people what node event emitters are etc. |
Please describe the problem you are having in as much detail as possible:
My server lost connection to the internet and on_closed throw an error on emit(-1)
I don't know how to reproduce the issue.
The text was updated successfully, but these errors were encountered: