Hate Writing Try...Catch In Node.js? Do This Instead

This isn't really nodejs, as so much as it is express.

While this works, it just isn't a good pattern to use for a number of reasons. First of all it doesn't well track your errors, it doesn't provide good handling when you want to capture the problem.

And most problematic is that it isn't better than the alternative. Here's why:

• New developers to your project won't know to do this, you introduce bad required domain knowledge to your services. This is never the right thing to do.
• Additionally, there is no way to ensure that everything is wrapped correctly, a PR that introduces a new route that doesn't contain use might go unnoticed, making the whole pattern moot.

Better than doing this at all, is to just rely on the framework patterns. openapi-factory uses middleware, express uses error function fallbacks, etc... Almost every framework has one, just use those, and stop trying to reinvent a different pattern in node.

A global error handler is definitely something that should be in every web project, but with some caveats.

As mentioned in @wparad's comment, newer developers could miss the use function, and then you have subtle bugs in your code - the worst kind. Thankfully, this can largely be fixed by patching express a little so that it works as you'd expect, even for async errors.

Also, I wouldn't use this for all errors. In the global error handler for Nodewood, I try to catch specific 4xx-class errors first and use them to display specific API messages that the UI knows how to consume, then display a generic 500 message for everything else.

But there are all kinds of places where try/catch makes a lot of sense. For example, if a user hits a unique error when trying to insert into the DB, you can try/catch that and use it to re-throw a more-specific error message that your global error handler can then display directly, with safe-to-display error text. You still use try/catch all over your app, but not as repeated boilerplate, instead to add more application-specific smarts and error handling.

I only skimmed through the video, but I think I got the gist of it.
Handling errors in your middleware is not a bad idea, but a catch-all is probably not the solution. It's really only useful as a fallback for parts of your code where you only implement the happy path at first.

My tips:

• Generate a unique ID for every error and display it to the user. Call it something like error-instance-id.
• Log errors into a service like Sentry, and make sure to add the same error ID to the event.

Then when a user tells you: "I did action A, B, and C and then I got an internal server error", you can look up that exact error in Sentry.

That reminds me of an alternative pattern for try/catch. I think it's inspired by philosophies in the Go programming language. The "happy code path" is the least indented, so it's easy to visually follow the non-error flow of the program.

When an if (error) happens the code is indented with error handling logic. This gives a nice separation between the happy path and the error path.

let error;

const firstResult = await firstPromise.catch(e => (error = e));

if (error) {
  // handle error in first promise
}

const secondResult = await secondPromise.catch(e => (error = e));

if (error) {
  // handle error in second promise
}

// ... and so on

If you like this style, use it. But remember your teammates might not "get it" at first. 😉

PS. I like it. 😎