[ef4]

I have designed and deployed production web services built on node, so I am intimately familiar with where it's strengths and weaknesses lie.

And clearly the node devs agree with me that error handling is a problem, because they went and invented Domains to try to solve this problem, and then explicitly documented (http://nodejs.org/api/domain.html) that Domains don't achieve exception safety. Something that almost any other runtime environment can do.

The "there was an exception, anything can happen" argument is a cop out. There's no excuse for leaking references just because the stack was unwound by an exception instead of normal function returns. The real issue is that the language lacks a true asynchronous fate-sharing construct, that works no matter how your dependencies handle their own error conditions. Being asynchronous doesn't make this problem unsolvable. Erlang does it nicely.

If you need to crash and respawn every time somebody hits an exception, you're really easy to DOS, because anybody who can cause you to hit an exception can make you start to behave like a forking web server.

[matthieupiguet]

You can always use process.on uncaughtexception to avoid crashing the app. All your client is going to see is a timeout and you can set it up so as to receive an email omwhel this happens