| Check https://news.ycombinator.com/item?id=6211284 The design philosophy is pretty much the same as RoR's stack. The idea in Node is that modules are simple, replaceable and composable: Express is a simple facade to Node's HTTP server (wrapping raw HTTP requests and providing a middleware framework) on which you can plug in new middleware (again, small modules) which do a single job well. You can build full frameworks out of this system without the hurdle of these frameworks being monsters: just plug in the appropriate middleware for each relevant route and you're done (and, thanks to Connect/Express this plugin will work in every framework using Express as a building block). There's nothing wrong with it, and it comes with many advantages. So, to answer your question: yes. Node is not responsible of handling error conditions because that's not Node's job: it's part of userland. Node is just a simple IO engine, not a web server! The full stack looks like this (similar to RoR's): Node (Async IO) -> Express (Request facade) -> Connect (Middleware handling) -> Middleware and/or Framework -> Your app. |
Why is the "string" implementation part of Node, and not something that everybody can choose to implement with their own microlibrary? Because strings are something that need to pass between modules all the time, and interoperability dictates that we should all pass the same kind of strings.
Likewise, exceptions flow between modules. They are necessarily part of the interface that other people's code will expose to yours. That's why Exception is part of Node, and that's why it's Node's responsibility to give us constructs to deal with those exceptions cleanly. It tries to do so, with try/catch/finally (which only works on purely synchronous code), and Domains (which can work with asynchronous code, but only if all your dependencies are careful to also use Domains to clean up their references, which most don't).