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

[ef4]

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.

[matthieupiguet]

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

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

[616c]

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

[matthieupiguet]

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

[taude]

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

[kaoD]

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! :)

[andreypopp]

So Rack doesn't handle errors properly now?

Node.js error handling sucks, period.

[matthieupiguet]

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)

[andreypopp]

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