Error handling in Node.js and Express | Hacker News Reader

Error handling in Node.js and Express

itamarweiss.com

25 pointsitamarweiss21 comments

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-domain-errors

https://github.com/superjoe30/naught

Sounds good. I'll have a look.

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

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.

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.

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

> 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

[1] http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2...

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.

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

Simply put because node is NOT an http server, that's a common misconception

Except, we're talking about Express here and not barebones Node.js. Express implies a web framework competing against all the techs you listed: Rails, Grails, Django....

Not at all. Express is more like Rack than Rails. It provides routing and middleware setup... and that's pretty much it. It's a microframework designed to be minimal, so you are crticising its core design.

You should compare Rails/Django to full-fledged frameworks such as Geddy/Tower/Locomotive/Meteor/Compound... Many of these frameworks are built on top of Express, leveraging it just like Rails/Sinatra leverage Rack.

That's why you should never criticise what you don't know! :)

So Rack doesn't handle errors properly now?

Node.js error handling sucks, period.

Well, you do seem to be an expert ... Error handling works pretty well if you know how to code (we run a seever in production with 2M requests per day on node and we manage errors pretty well)

I didn't say it is impossible, it just sucks compared to other platforms/languages.

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.

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

Express does return a 500 on exception by default. This article showed details about how to customize the error page.

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

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.

Seems rather nice :) Thanks

Reply on news.ycombinator.com