It's Node.js - the root of the problem is also Node's strength, which is that there's effectively no stack. You can manage zillions of concurrent connections, but there's no easy way for the system to unwind bad behavior by one of those connections.
In a Java app you except all the way to the request response.
In a Go app you return all the way to the request response.
In a Node app, you have to call your way back to the request response. Or you don't, potentially leaving the whole process in an inconsistent state. The amazing concurrency of node comes at a price.
Domains were Node's answer to that, and it seemed to work pretty well. I adopted the approach for my own web framework (not JS based) and it has been an extremely useful abstraction.
They're soft-deprecated in Node now though, and AFAICT work on a replacement has stalled.
And in async C# - which has the same "amazing concurrency" - it just works. Because the language will take that exception, and wrap it into a faulted task (promise) for you. So the stack may be spaghetti, but exceptions navigate it correctly same as everything else.
It's common for people to complain about something like a syntax error taking down their whole process, so that's how I read it -- that you're trying to do "too much" catching.
I'm not an expert with deploying application servers but shouldn't part of handling lifecycle include the ability for a service to crash and be respawned?
Ie. Be okay if a syntax error crashes your server.
In a "one request per process" model, sure. But if you are handling 1000s of concurrent connections, a syntax error crashing your server means all of those connections error.
If you're comparing to J2EE, ASP.NET, Apache, etc, application servers tend to be big monoliths with lots of features, but Node is much lighter / more modular, so you end up setting that up yourself (that also surprised me)
Yeah, I'm happy to admit that I figured out how Node/Express work entirely by doing things wrong, and then fixing my mistakes :)
I came to this after building C#, Scala, and Java webapps, so it surprised me that this these class of coding errors could take down a site (both screwing up the try/catch or not handling promises).
There is probably some room for Node/the language/Express to make the experience better, either way it's something you'd need to know if you're new to the platform :)
You can execute everything inside a promise like with Koa, which amounts to something like:
Where `handle` is an async function and thus all your application logic is in async/await space.