

Error handling in Node.js and Express - itamarweiss
http://www.itamarweiss.com/post/57962670227/error-handling-in-node-js-express

======
mathrawka
Add a route that does something like

    
    
      throw new Error('Uh oh')
    

Error handling done right will include a way to catch the error. With current
versions of Node.js that means to use domains.

And then you want to make sure that a crash will not cause other concurrent
connections to get abruptly disconnected.

I have a few things in place that I use to get zero-downtime deploys and crash
handling.

[https://github.com/mathrawka/express-graceful-
exit](https://github.com/mathrawka/express-graceful-exit)

[https://github.com/mathrawka/express-domain-
errors](https://github.com/mathrawka/express-domain-errors)

[https://github.com/superjoe30/naught](https://github.com/superjoe30/naught)

~~~
itamarweiss
Sounds good. I'll have a look.

------
ef4
That this article can claim to be error handling "done right" is a great
illustration of the immaturity of the node ecosystem.

Stop and ponder that express can't even return a 500 on exception without a
lot of customization. (Which this example doesn't even address.)

~~~
louischatriot
You don't seem to know a lot about node. The whole philosophy is "small
modules that do one thing well and get out of the way for the rest". If what
you like are big frameworks that handle these kinds of things for you, e.g.
Rails, Grails, Django ...

Don't pick on Node for not doing something it was not created to do, and will
never do.

~~~
kevingadd
Node was created to not handle error conditions? How is that defensible in a
HTTP server?

~~~
kaoD
Check
[https://news.ycombinator.com/item?id=6211284](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.

~~~
ef4
That argument is a cop out, because I can apply it to lots of other things
that node _does_ do.

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

------
louischatriot
Nothing new under the sun. The 404 trick is useful but usually it makes the
code more readable to handle errors in your request handlers. That way you
don't have to jump between the error handler and the request handler.

------
madsravn
Seems rather nice :) Thanks

