Recently I was looking into monitoring static websites and it got me thinking about global error handling. There’s a good chance that you’ve come across the
onerror global handler that’s triggered when an error happens and there’s no
catch around it. But how does this work when working with Promises?
Promise Error Handling
Let’s take this example:
There are two errors that could happen here, the first is a network failure and the other is the response isn’t valid JSON (side note,
fetch doesn’t return an error on a 404 or 500 respose), but we’re not doing anything to handle those errors so we’d need to rewrite it like so:
Now we are handling the rejection and our application is all the happier for it.
Handling the Unhandled
In an ideal world, you’re handling all errors that an application may have, but in reality that’s not the case, there will be errors that were not planned for, which is why we have
onerror is for handling errors that didn’t occur within a Promise, for that we need to look elsewhere.
Promises don’t error per se, they reject (which can represent an error or just being unsuccessful), and that rejection may be unhandled which will result in the
unhandledrejection event being triggered.
onunhandledrejection can be assigned directly off
window like so:
This is similar to
onerror, but it doesn’t have quite as much information provided. All you receive in this event handler is the Promise that failed and the “reason” provided to the rejection. This does mean that you don’t get some useful information like source file or line number, but that’s a trade-off because it’s come from an async operation.
You can also call
preventDefault on the error object which will prevent writing to
console.error, which can be useful if you want to avoid leaking information to the debug console.
Handling the Handled
While you can capture unhandled rejections you can also capture handled rejections using the
rejectionhandled event. While I find it annoying that it’s an inconsistent name (Rejection Handled to go along with Unhandled Rejection, why aren’t they consistent with where the word Rejection is!) this event handler works the same as the other one but will be triggered when a
catch handled is provided.
This handler is useful if you’re doing a monitoring platform you might want to log all rejections, handled or not.
If you’re building an application you should always look to include global error handling. It’s very common to handle
onerror but it’s quite easy to forget about global error handling for Promises and that’s easy to do with