Error handling in Node.js and Express
itamarweiss.com
Error handling in Node.js and Express
1–10 of 23 posts
Re: Error handling in Node.js and Express
#2Add a route that does something like
throw new Error('Uh oh')
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
Re: Error handling in Node.js and Express
#3[deleted]
Re: Error handling in Node.js and Express
#4Add 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/mathraw…
Sounds good. I'll have a look.
Re: Error handling in Node.js and Express
#5That 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.)
Re: Error handling in Node.js and Express
#6That 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.
Re: Error handling in Node.js and Express
#7Nothing 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.
Re: Error handling in Node.js and Express
#8That 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.
Re: Error handling in Node.js and Express
#9That 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.
Node was created to not handle error conditions? How is that defensible in a HTTP server?
Re: Error handling in Node.js and Express
#10Earlier 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?
> 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...