Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Error handling in Node.js and Express

itamarweiss.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Error handling in Node.js and Express

#11

Post by taude »

louischatriot wrote: post #8
ef4 wrote: post #5

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

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.

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

Re: Error handling in Node.js and Express

#12

Post by kaoD »

taude wrote: post #11
louischatriot wrote: post #8

Earlier quoted context omitted.

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.

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

Re: Error handling in Node.js and Express

#13

Post by kaoD »

kevingadd wrote: post #9
louischatriot wrote: post #8

Earlier quoted context omitted.

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?

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.

Re: Error handling in Node.js and Express

#15

Post by andreypopp »

kaoD wrote: post #12
taude wrote: post #11

Earlier quoted context omitted.

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…

So Rack doesn't handle errors properly now?

Node.js error handling sucks, period.

Re: Error handling in Node.js and Express

#16

Post by scriby »

ef4 wrote: post #5

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

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

Re: Error handling in Node.js and Express

#17

Post by ef4 »

scriby wrote: post #16
ef4 wrote: post #5

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

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

Re: Error handling in Node.js and Express

#18

Post by ef4 »

louischatriot wrote: post #8
ef4 wrote: post #5

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

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.

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.

Re: Error handling in Node.js and Express

#19

Post by ef4 »

kaoD wrote: post #13
kevingadd wrote: post #9

Earlier quoted context omitted.

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

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 framework…

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

Re: Error handling in Node.js and Express

#20

Post by matthieupiguet »

ef4 wrote: post #18
louischatriot wrote: post #8

Earlier quoted context omitted.

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.

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…

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
Post reply on HN