You have probably heard about ES6’s built-in Promises and how they can provide a way out of JavaScript’s callback hell.
While the intend and purpose for Promises is clear very quickly, getting used to them is not as straightforward and the devil lies in the detail.
One thing that bit us quite late during a recent refactoring and has caused a lot of frustration was the fact that Promises “swallow” exceptions by default.
This does include exceptions such as ReferenceError so that the following code runs perfectly fine, without ever letting you know that something went wrong:
var myPromise = Promise.resolve(); myPromise .then(function() { console.log("Step 1"); }) .then(function() { console.log("Step 2", thisNameDoesNotExist); }); |
What happens here is that the implementation of Promise wraps our function (the onFulfillment handler as it is called in the language specification) in a try-catch block. Instead of throwing the error and causing our interpreter to crash (but print a convenient error message at least), it catches it and marks the promise p as rejected.
Those of you who have worked with Promises before will say that you need an onRejection handler function of course, and you are perfectly right:
var myPromise = Promise.resolve(); myPromise .then(function() { console.log("Step 1"); }) .then(function() { console.log("Step 2", thisNameDoesNotExist); }, function(e) { console.log("Promise rejected, error:", e); }); |
However, this still doesn’t work. What is wrong here? In order to catch errors in the last actual onFulfillment handler in our chain, we need to add another step where nothing but the error catching happens. We could use another .then() with an empty function as its first argument, but a more elegant way is to use .catch() which takes only the onRejection handler for its arguments:
var myPromise = Promise.resolve(); myPromise .then(function() { console.log("Step 1"); }) .then(function() { console.log("Step 2", thisNameDoesNotExist); }) .catch(function(e) { console.log("Promise rejected, error:", e); }); |
Much better, that will do. In theory. In reality though, it is very easy to forget to specify the .catch() handler at the end, have it in the wrong place etc.
Believe me, that will happen, no matter how careful you are. And if it’s not you who forgets it, it will be some guy on your team.
For that reason, Bluebird, one of the most popular Promise libraries, has a “default” onRejection handler which will print all errors from rejected Promises to stderr. This is a huge improvement and while it can still result in unexpected behaviour because it doesn’t interrupt execution, it at least gives a hint where things are dodgy.
While that is all well and good, we didn’t feel like using a library, now that we finally got native support for Promises from io.js. And as it turns out, you don’t have to. Because just as there is process.on(‘unhandledException’, ..), since its 1.4.1 release, io.js also has the unhandledRejection event, which is very similar to Bluebird’s default handler, except that you have to specify it yourself:
var myPromise = Promise.resolve(); process.on('unhandledRejection', function(error, promise) { console.error("UNHANDLED REJECTION", error.stack); }); myPromise .then(function() { console.log("Step 1"); }) .then(function() { console.log("Step 2", thisNameDoesNotExist); }); |
Do this once in your project and you will never have Promises swallow your exceptions again. Happy debugging!
