Node.js error handling
snmaynard.com
Node.js error handling
1–10 of 24 posts
Re: Node.js error handling
#2There seems to be an error in the final code snippet. Instead of d.intercept it should be mainDomain.intercept. Here's the original example: http://nodejs.org/api/domain.html#domain_example_1
Re: Node.js error handling
#3There seems to be an error in the final code snippet. Instead of d.intercept it should be mainDomain.intercept. Here's the original example: http://nodejs.org/api/domain.html#domain_example_1
Apologies for that, I've updated the example. Thanks for pointing it out.
Re: Node.js error handling
#4Finally a good explanation of error handling in node.js. Cheers!
Re: Node.js error handling
#5Unfortunately error handling in Node.js is a total mess.
As with most new technologies there are few standards and whatever standards there are are subject to change. It was only a short time ago that many Node.js libs were being produced with promises.
The most common style I see today is this callback style:
doAsyncCall(function(err, result){
if(err){ // handle err }
});
function doAsyncCall(cb){
// .. do some async stuff
if(// error has been thrown){
callback(err);
} else {
callback(null /* this is where confusion happens */, result);
}
}
I am personally a fan of the `if(result typeof Error)` style but it is not common. Many frequently used libraries, like Mongoose, use the (err, result) style.
Because any async call can theoretically fail, and because you need to catch every potential error, it is common for starting programmers (and even experienced ones) to miss an edge case or two. I advocate using upstart or a similar scheme to make sure your Node server stays alive, even if you happen to have missed an error somewhere.
Re: Node.js error handling
#6Unfortunately error handling in Node.js is a total mess. As with most new technologies there are few standards and whatever standards there are are subject to change. It was only a short time ago that many Node.js libs were being produced with promises. The most common style I see today is this callback style: doAsyncCall(function(err, result){ if(err){ // handle err } }); Unfortunately this is prone to error. When w…
One of the things I love about node.js is that it forces you to come up with a style and stick with it for things like this. At http://ratchet.io our API servers are written in node.js and we chose the foo(err, callback) method.
I personally love this style even though it makes you write more boiler-plate code, it forces you to write exception-safe code from the start. Also, it forces a structure on all of your code that you can instantly recognize as missing if someone forgets to check for err in the callback.
If you can stick with the style, it's fairly difficult to write code that doesn't deal with errors gracefully.
Re: Node.js error handling
#7Unfortunately error handling in Node.js is a total mess. As with most new technologies there are few standards and whatever standards there are are subject to change. It was only a short time ago that many Node.js libs were being produced with promises. The most common style I see today is this callback style: doAsyncCall(function(err, result){ if(err){ // handle err } }); Unfortunately this is prone to error. When w…
One of the things I love about node.js is that it forces you to come up with a style and stick with it for things like this. At http://ratchet.io our API servers are written in node.js and we chose the foo(err, callback) method. I personally love this style even though it makes you write more boiler-plate code, it forces you to write exception-safe code from the start. Also, it forces a structure on all of your code…
I agree. One of the advantages of the (err, result) style is that it puts error handling directly in your face. The `result typeof Error` style does not.
In any case all I care about is that we choose one, and (err, result) is gaining traction, which is fine. While many are excited about domains, I am not. From my perspective, in practice, it will just add another incompatible style onto the pile.
Re: Node.js error handling
#8Unfortunately error handling in Node.js is a total mess. As with most new technologies there are few standards and whatever standards there are are subject to change. It was only a short time ago that many Node.js libs were being produced with promises. The most common style I see today is this callback style: doAsyncCall(function(err, result){ if(err){ // handle err } }); Unfortunately this is prone to error. When w…
One of the things I love about node.js is that it forces you to come up with a style and stick with it for things like this. At http://ratchet.io our API servers are written in node.js and we chose the foo(err, callback) method. I personally love this style even though it makes you write more boiler-plate code, it forces you to write exception-safe code from the start. Also, it forces a structure on all of your code…
How do you deal with code where the author forgot to handle all of the failure cases and invoke the callback?
Re: Node.js error handling
#9Earlier quoted context omitted.
One of the things I love about node.js is that it forces you to come up with a style and stick with it for things like this. At http://ratchet.io our API servers are written in node.js and we chose the foo(err, callback) method. I personally love this style even though it makes you write more boiler-plate code, it forces you to write exception-safe code from the start. Also, it forces a structure on all of your code…
How do you deal with code where the author forgot to handle all of the failure cases and invoke the callback?
To be honest... since you can't try/catch, you can't do much.
You can catch the exception with something like this:
process.on('uncaughtException', function (err) {
console.err("Uncaught exception: " + err);
console.err("Uncaught exception stack: " + err.stack);
});
That's about the best you can do, unfortunately. You could always monkey patch the lib if you can figure out where it's crashing.
I recommend Longjohn(https://github.com/mattinsler/longjohn) for these sorts of situations; the extra stack trace lines become invaluable.
Re: Node.js error handling
#10Earlier quoted context omitted.
One of the things I love about node.js is that it forces you to come up with a style and stick with it for things like this. At http://ratchet.io our API servers are written in node.js and we chose the foo(err, callback) method. I personally love this style even though it makes you write more boiler-plate code, it forces you to write exception-safe code from the start. Also, it forces a structure on all of your code…
I agree. One of the advantages of the (err, result) style is that it puts error handling directly in your face. The `result typeof Error` style does not. In any case all I care about is that we choose one, and (err, result) is gaining traction, which is fine. While many are excited about domains, I am not. From my perspective, in practice, it will just add another incompatible style onto the pile.
Yeah, domains seem like a desperate solution. Will be interesting to see what eventually becomes the standard.