Six years ago, during the early days of node, Guillermo Rauch wrote a blog post titled A String is not an Error. It might seem obvious now, but at the time, node didn’t really have any established patterns. That’s around the same time the error-first-callback pattern evolved as the standard way to return errors.

When working with callbacks, functions can return errors via two distinct channels. Developer errors throw exception while run-time errors are returned via the callback’s first argument. With the move to async/await these two channels merge back into one. The problem is, the common pattern of purposely ignoring some callback errors is no longer safe.

Consider the following snippet, used to log incoming registration requests but not others request types (ignore the fact this code isn’t actually asynchronous, I want to keep things simple):

The same code rewritten to use async/await instead of callbacks appears to be doing exactly the same thing:

However, these two are not the same. In the callback version, an invalid request missing acategory property will throw a ReferenceError exception while the second exceptions throwing version just ignores the bug silently.

Unlike other languages, JavaScript doesn’t provide a built-in way to selectively ignore some errors but not others. What we need is a way to say, ignore any application error thrown, but still let bugs make it to the surface.

One way to accomplish this is with the Bounce module. Bounce provides a simple rethrow(err, types) method that matches the error against a prototype, error category, or pattern, and if the error matches, rethrows it. If it doesn’t, the error is ignored. It also provides the opposite method ignore(err, types) .

In this case, we want to rethrow system errors — language errors such as bad syntax and missing references — but ignore the errors thrown by our own (intentional) logic.

All it takes is adding Bounce.rethrow(err, 'system') in two spots:

As a general rule, if you are catching errors and not processing the err object caught, you are likely swallowing errors which is bad. Not knowing your application is failing is far worse than failing and being able to fix it.

A more, typed-language approach would include creating an application-specific error type:

class MyAppError extends Error {}

And then using:

Bounce.ignore(err, MyAppError);

async/await is going to change the JavaScript landscape over the next couple of years. Modules like async which power almost every node application today are going to be obsolete, replaced by new patterns.

Learning to use try…catch after years of callback is going to take some practice. Help yourself by following this simple rule: never ignore the err thrown, and if you must, comment your code to explain why this is safe and name the variable ignoreErr to make your intentions clear (and your linter happy).

Continued in Catching without Awaiting.

Learning to Throw Again was originally published in hueniverse on Medium, where people are continuing the conversation by highlighting and responding to this story.