Hacker News Reader

Comment by toxicFork | Hacker News Reader

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)

View on HN

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.

C++ - couldn't you just put a catch(...) within your request handler and return 500 if that is hit?

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).

Stops the entire process dying though, so you can keep on serving?

And you can do the same on node :)

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.

Deleted comment

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.

If you've set PDO::ATTR_ERRMODE to throw exceptions and you're still seeing warnings then yes, that's a bug in PHP. Perhaps you could submit it.

Reply on news.ycombinator.com