Question

I’ve heard from plenty of people saying that throwing errors in Node is bad practice, and you should rather manually handle them via CommonJS’s callback syntax:

somethingThatPassesAnError( function(err, value) {
    if (err) console.log("ERROR: " + err);
});

Yet, I’ve found in multiple unit testing frameworks (Mocha, Should.js, Gently) that it seems like they want you to throw an error when something happens. I mean, sure, you can design your tests to check for equality of variables and check for not-null in error vars, but in the words of Ryan Dahl himself, “you should write your framework to make the right things easy to do and the wrong things hard to do”.

So what gives? Can anyone explain why that practice exists? Should I start throwing fatal exceptions like require() would if the module couldn’t be found?

Answer 1

It because nodejs programs typically make heavy use of async, and as a result errors are often thrown after your try/catch has already completed successfully. Consider this contrived example.

function foo(callback) {
  process.nextTick(function() {
    if (something) throw "error";
    callback("data");
  });
}

try {
  foo(function(data) {
    dosomething(data);
  });
} catch (e) {
  // "error" will not be caught here, as this code will have been executed
  // before the callback returns.
}

The typical node pattern, of the first argument in a callback being an error, obviates this problem, providing a consistent way to return errors from asynchronous code.

function foo(callback) {
  process.nextTick(function() {
    if (something) return callback("error");
    callback("data");
  });
}

foo(function(error, data) {
  if (error) return handleError(error);
  dosomething(data);
});