8 ms·

Error handling in Node.js and Express

25 points by itamarweiss 13y ago

mathrawka 13y ago
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 13y ago
  Sounds good. I'll have a look.
deleted 13y ago
[deleted]
ef4 13y ago
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.)
- itamarweiss 13y ago
  There are some advantages to the customization options that Express offers. Sometimes when there's an exception, you might even prefer to have the server fail and restart, so that it doesn't stay in an undefined state. If you're hosted on Heroku, like I am, then they take care of the error message for you. If you have several live servers, they also do the load balancing while the server restarts.
- louischatriot 13y ago
  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 13y ago
    Node was created to not handle error conditions? How is that defensible in a HTTP server?
    - 616c 13y ago
      > Node was created to not handle error conditions? How is that defensible in a HTTP server? It depends on what you expect, giving the programming language, runtime, and the philosophy of those who developer the former, latter, or both. Erlang is famous for the "let it crash" tenet [0], and I doubt you get something most programmers are comfortable with. However, I doubt most programmers I know (I will not assume about others) can scale to WhatsApp, which more or less runs a REST API on Erlang to great scale. [1] This is not to say the two things are perfectly related, but there are different methods and philosophies around error handling and conditions. Some are comfortable with Node, others are not. [0] http://c2.com/cgi/wiki?LetItCrash http://c2.com/cgi/wiki?LetItCrash [1] http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2...
    - kaoD 13y ago
      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.
- scriby 13y ago
  Express does return a 500 on exception by default. This article showed details about how to customize the error page.
  - ef4 13y ago
    Only if you get lucky enough to hit the exception on the initial call stack. If you do anything asynchronous first and then throw the exception, express just either leaves the client connection hanging (if you trap and log unhandled exceptions) or crashes all client connections (if you don't).
louischatriot 13y ago
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 13y ago
Seems rather nice :) Thanks

25 points by itamarweiss 13y ago

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 13y ago
Sounds good. I'll have a look.

deleted 13y ago

[deleted]

ef4 13y ago

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

itamarweiss 13y ago
There are some advantages to the customization options that Express offers. Sometimes when there's an exception, you might even prefer to have the server fail and restart, so that it doesn't stay in an undefined state. If you're hosted on Heroku, like I am, then they take care of the error message for you. If you have several live servers, they also do the load balancing while the server restarts.
louischatriot 13y ago
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 13y ago
  Node was created to not handle error conditions? How is that defensible in a HTTP server?
  - 616c 13y ago
    > Node was created to not handle error conditions? How is that defensible in a HTTP server? It depends on what you expect, giving the programming language, runtime, and the philosophy of those who developer the former, latter, or both. Erlang is famous for the "let it crash" tenet [0], and I doubt you get something most programmers are comfortable with. However, I doubt most programmers I know (I will not assume about others) can scale to WhatsApp, which more or less runs a REST API on Erlang to great scale. [1] This is not to say the two things are perfectly related, but there are different methods and philosophies around error handling and conditions. Some are comfortable with Node, others are not. [0] http://c2.com/cgi/wiki?LetItCrash http://c2.com/cgi/wiki?LetItCrash [1] http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2...
  - kaoD 13y ago
    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.
scriby 13y ago
Express does return a 500 on exception by default. This article showed details about how to customize the error page.
- ef4 13y ago
  Only if you get lucky enough to hit the exception on the initial call stack. If you do anything asynchronous first and then throw the exception, express just either leaves the client connection hanging (if you trap and log unhandled exceptions) or crashes all client connections (if you don't).

louischatriot 13y ago

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 13y ago

Seems rather nice :) Thanks