Gawdl3y
commented
6 years ago As already explained on numerous occasions, this is standard behaviour for a Node.js application utilising EventEmitters (see the docs here). But no, since this behaviour clearly infuriates you so much, go ahead and switch to Eris (the only other actively-developed JavaScript DAPI lib at this point). Oh wait...
That's okay though, you can obviously just switch to an entirely different language to get away from the undesirable fatal errors/exceptions... No, damn, that won't work either. Java, C#, C++, Rust, Python, Go, Ruby and Dart all treat exceptions/errors as fatal by default. But it's okay, at least if you stick with PHP it won't crash when an error happens! ... Uh-oh, PHP does, however, issue fatal errors for uncaught exceptions. What a shame. It's almost as if the entire community of programmers have collectively decided that suppressing errors by default is very poor behaviour - they're clearly all out to get you!
But hey, it'll all be okay! Just like you wanted, JavaScript/Node.js actually has a feature to allow you to catch these error events and not treat them as fatal! Would you like to know how it's done? Here it is:
client.on('error', console.error);Phew, that's a doozy. It's a good thing it's written out for you, though, so your fingers don't get hurt. And just in case you do want the errors to be fatal (as many people do, since it's often safer to bail and start all over - see PM2 to assist with this), but still log good information about them, here's another incredibly complex snippet of code for your shameless enjoyment:
client.on('error', err => {
console.error(err);
process.exit(1);
});This "esoteric line" is not spelled out for you in the discord.js documentation because they're not Node.js tutorials. You are expected to understand how error events and uncaught exceptions behave in this environment. You should also know how to read and comprehend error messages and stack traces, especially considering these are not unique to Node/JavaScript. Additionally, everybody wants different results for handling/logging errors - it'd be dumb as hell for the library itself to do any of it for you. Basically every library/framework in existence is going to expect you to handle errors in some way/shape/form.
I have yet to see a reproducible example where catching the error event doesn't solve someone's crashing from an error emitted within the library. If you have one, by all means, share it.
You seem to be relatively new to the Node.js ecosystem, which is totally understandable. That's completely fine - we all start somewhere. What's less okay, however, is posting multiple comments/issues about the same topic, filled to the brim with barely-veiled attacks and meaningless threats to the contributors. If you want to continue discussing this, for whatever reason, cool down a bit.
ghost
I spent most of my time in my comment addressing the point that you definitely did raise (and spent the most time bitching about). Sounds reasonable to me.
eponymz
Triforcey
adamschachne
devsnek
appellation
iCrawl
This is a design and philosophy issue with discord.js that frankly makes me look for other libs that don't have this problem.
Throwing errors in javascript is equivalent of fatal errors in other languages, and as it stands that means any little error, such as Error: read ECONNRESET happening every 2 days to a week means your discord bot will crash, without a line number reported in your code, and with a very general error that doesn't aide in debugging at all. You only get this error if you do: client.on('error', console.error);
General bot examples don't have this line, and others have reported this line not working for them to resolve this issue: Error [ERR_UNHANDLED_ERROR]: Unhandled error. ([object Object]) at Client.emit (events.js:171:17)
This has been brought up in "many duplicate tickets" on github for discord.js and the response from devs seems to be to shift the blame onto end programmers for their bad design choices. The result is a library that makes bots that crash randomly, with error messages that aren't at all helpful. What if PHP curl crashed your entire web application every time there was a network error? It's just totally bad design and you can try to hide behind "but programmers need to handle errors", but even web browsers that rely on javascript don't crash a page and try to have graceful errors as MUCH as possible. The design here is opposite of that, if any little thing goes wrong, better have wrapped the entire thing in an error handler. client.on('error') doesn't even make sense as an event.
It makes you sound like you want try/catch blocks on every line or wrapping an entire program, which is silly in itself. Considering the fact your OWN examples in your documentation do not use this line, and also do not wrap any try/catch around the client creation, or have then/catch and would be susceptible to the exact same problems that keep getting reported and blamed on the programmer who brought it up, then I think it's kind of check and mate as far as this being just poor design, or a bug goes. Take your pick. Because I'm not for using libs that make my bots crash randomly, if you guys aren't going to fix it (as others have reported even this esoteric line not making it work for them), then I'll find a lib that doesn't have a long standing issue purposefully ignored by the devs.
Try catch blocks are a pitfall if you don't use them right, and they should be rare and only for fatal errors in javascript because unlike more graceful langauges that emit notices and warnings more often, javascript tends to just die, and itself doesn't even have a die function and people use throw error as a substitute for it because it's so great at killing your program! A notice or warning of a connection reset would be far more fitting than crashing my bot if I don't have a catch all error handler for the client, which any lib should actually have built into the client itself and allow overriding if the dev chooses, not default to blowing up your application/bot.