> Plenty of times, there will be an uncaught exception which–through no fault of your own–bubbles up and kills the whole process.
Really? I'm just a beginner with node.js, and I've been deeply frustrated by error handling, but if this is true, that's pretty damning. In just about every other web framework under the sun, you can go wild with exceptions and the worst you'll get is a 500 response for that request. (Yes, worse behavior is possible but very uncommon.)
Same happens with Java, C++, and many other languages.
There are web server packages on node that do catch errors that happen in synchronous code. For async, you can use promises, which take errors into consideration.
I'm not sure what happens on unhandled async errors on other languages, I guess in Java you could have a dangling request (happened to me before) or it could crash the app (also happened to me before). C++? I haven't really done much webserver work on that one so someone else may be able to write more about it.
Also obviously PHP, you just get a white page or actual full error stacks sent to the client, the joy! (edit: of course, if you don't handle it properly)
You CAN get a white page or an error message by default, you don't "just get" them. It doesn't make any sense either because (surprise) you can and should configure that away. I see your edit but what's the point of that sentence other than to jab at PHP?
It's only because I have worked on php projects where my involvement started since various degrees of completion, and these issues happened to me most frequently. My point was that PHP can be configured (or not) to handle errors better, but so can node.
Yes you can do a global catch, but the error still happened, the functionality was faulty and you didn't handle it properly (you just showed the error, period).
not if you are using any kind of event emitters. These don't participate in any kind of flow but fire "error" events as side effect sneakily in the background, and if there is no listener on an event emitter for the "error" event, it will crash the server. And almost everything in core is an event emitter.
Also bonus points if the event emitter object is private to some module that doesn't expose it and doesn't attach an "error" event handler to it.
promises makes async error handling easier but it does not solve it yet. It is very easy to miss an error handling and end up with errors that goes to /dev/null leaving you with no trace of what happened. When the tools and the language evolve it will hopefully work better.
There's nothing in PHP that stops it sending correct HTTP error codes. Incompetent developers might write things that throw blank pages or stack traces, but that's true of any language.
I've run into issues with php where it always outputs the warning as a table. Recently I was working on an in house project that used the mysqli extension. It's being deprecated for PDO and outputs a warning of this as an html table.
I didn't have time to port this to the new library. I had to disable deprecated warnings to get rid of this, but I'm left fearing there might be other warnings somewhere else in the project that will print these tables as well, which naturally fucks with the json deserialization stage client side. A scary thing about this is it disables ALL deprecated warnings, and the warning is no longer even printed in the error log.
The fact that there is no way for me to say "don't print errors and warnings in the http response, but instead just put it in the log" is concerning to me. I know this is beating a dead horse but the language really needs standardized errors. Give me exceptions or return values, I don't care. Anything is better than printing the fucking warning in the http response.
Really? I'm just a beginner with node.js, and I've been deeply frustrated by error handling, but if this is true, that's pretty damning. In just about every other web framework under the sun, you can go wild with exceptions and the worst you'll get is a 500 response for that request. (Yes, worse behavior is possible but very uncommon.)