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

[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.