Improve Application-wide Error Handling rethrowing JavaScript Error with the Error Cause

Tomasz Ducin
InstructorTomasz Ducin
Share this video with your friends

Social Share Links

Send Tweet
Published 5 months ago
Updated 2 weeks ago

The new cause data property that you can add to a thrown Error can be used to retain access to the original error caught in a promise rejection.

[00:00] Create an async function, which will load some external data. In our case, we're going to use the fetch API, but if you want to use a different API for ATP requests, it does make a big difference. So we're pretending that we would run a request against a URL that doesn't [00:19] exist, and that's because we want to trigger a situation where the request fails and we want to process the error handling. So in some situations, you would like to catch the error, send it to an external monitoring service, whether it's in your infrastructure or an external [00:39] paid infrastructure. You would like to send it to the monitoring and then rethrow the error so that your application layer, whether it's framework a or framework b, would process it further. So let's catch our error. And when the error is here, what we would like to do is to send this [00:59] log to this monitoring service, whatever that is. And for this reason, let's create this function, const send log. Most probably in most production applications, this would be a function which comes from some SDK coming from the external vendor. In our case, what we're going [01:19] to mock here is basically a function that basically runs a console log. So let's imagine that this is basically a function from an external vendor SDK. So what we're doing is first we want to send this error to the external service And what we want to do now [01:39] is to rethrow the error so that our application could proceed with error handling just as this catch would not exist here. So we could just rethrow the error with some custom message and that is loading stuff failed or whatever the message is. And using [01:58] the error cause, which is the new thing in JavaScript, we can pass the second parameter, which is an option back where the cause property accepts what is the error over here. So let's create this function and let's run this function actually. So what we see is that, first of [02:18] all, this is the original error and this is the error that has been re thrown but hasn't been processed further. And this is, of course, our external monitoring, this mocked function, this send log. So how we can actually make use of this cause is when we would run [02:38] this fetch stuff function again. So let's try to run this function. And here, using a catch, we would catch this error, of course. And what we can see here is that we can console log or use it in any other way. What is the error itself, but we can also [02:58] see what is the cause of this error. So that we have both access to what was our custom message, but also what was the original message in the original error being thrown by fetch or other HTTP API.

egghead
egghead
~ an hour ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today