
Error Handling in Nodejs - jessaustin
https://www.joyent.com/developers/node/design/errors
======
inglor
This gets so much easier with promises it's amazing:

1\. You can `throw` in async functions (when things are promisified) and
`.catch` async errors.

2\. You can't forget the error handling or ignore the `err` parameter, it will
propagate until you handle it.

3\. Did I mention propagation like with sync errors yet?

4\. It's easy to build exception hierarchies. Libraries like bluebird provide
typed and predicate catch blocks that let you do exception handling the way
you want like in other languages.

5\. Did I mention async/await or coroutines yet? You can use normal try/catch
with promises as a language feature.

6\. No Zalgo, if something might be async it should always be async to
preserve execution order. `then` always runs asynchronously which means no
timing issues and race conditions in errors and success values.

~~~
bsimpson
The biggest mistake in JS Harmony is silently swallowing async errors by
default unless you add a .catch to a Promise chain.

~~~
inglor
Not if I can help it :) In io.js this is no longer an issue, you have a
process event you can catch on "silent errors" to make them loud. This lands
in NodeJS soon. Bluebird promises don't behave this way and have never done
so.

~~~
grandalf
great! BTW would you use bluebird or es6 promises if starting a new project
today?

~~~
phpnode
inglor is a contributor to Bluebird, so I'd guess he'd say Bluebird. Bluebird
is the much faster option and has a lot more features, if you're using babel
(and a recent node/io.js) you can transpile async/await to bluebird coroutines
for maximum performance and syntactic beauty.

~~~
grandalf
Is there any chance Bluebird will become the standard in the future? Not sure
if it makes sense to use a nonstandard approach, but would love to be
convinced otherwise.

~~~
phs2501
IMHO, very doubtful; Bluebird has a lot of (very useful) features that would
be pretty burdensome to put into a specification.

On the other hand, there's really no reason not to use Bluebird. It's easy to
ensure that a promise you receive is a Bluebird promise:

    
    
        import Bluebird from 'bluebird';
        const bluebirdPromise = Bluebird.resolve(promise);
    

If `promise` is a Bluebird promise that will be a no-op, and if it's a foreign
promise or thennable you'll get a new Bluebird promise that will
resolve/reject when the foreign one does. (This is standard behavior; see
[https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Promise/resolve))

Since Bluebird promises are thennables, the reverse will be true if they're
consumed by a different promise library.

Given Bluebird's speed, superior debuggability, and features, there's really
no reason not to use it a this point.

~~~
grandalf
thanks much for the explanation. I will try bluebird.

------
kbody
I've been using Babel to experience the ES6/7 world and it's a great
experience to use async/await among else.

Like others have said the error handling is not ok, however I want to focus on
another related thing.

The use of try{}catch{} for handling errors. Awaken by a section on Pragmatic
Programmer and a post [1] of ZeroMQ's Martin Sústrik on (C) error handling. It
seems logical to me that try/catch should be used for unexpected behavior and
not for expected "falsy" results which is a core case for their current use on
ES6/7.

It is convenient to use try/catch compared to past alternatives, but it
doesn't feel nor is designed right. Instead of just going with it, until we
get terribly tired of it and do something, it's still early enough to have a
proper solution in place.

Not sure if any committee is working on this or something else is planned.

[1]: [http://250bpm.com/blog:4](http://250bpm.com/blog:4)

------
fibo
Very good article. It is also good to see Joyent writing Node documentation, I
hope they can centralize the Node ecosystem and avoid fragmentation while take
benefit of an open develop with IO.js fork.

~~~
LewisJEllis
That document has been around since March of last year; it's not a terribly
recent thing. See also: [https://www.joyent.com/blog/best-practices-for-error-
handlin...](https://www.joyent.com/blog/best-practices-for-error-handling-in-
node-js)

~~~
jessaustin
Presumably TFA isn't dated because it's considered "timeless". Nevertheless if
I could still edit the title I'd add a "(2014)".

