In this video, let's talk about error handling with fetch requests. js, I've got a try-catch block set up that wraps a fetch request to a non-existent site. This domain right here doesn't point to any server whatsoever, which means we'll have a network timeout. That's exactly what you see over here in the browser.
I've had this request running for over 90 seconds now. So I started it before I started the video. And here we get that error. And you can see that the catch block did indeed catch it because we've got this console log that we've written in the catch block actually running in the console here.
Okay, so by default, the Chrome browser will time out a fetch request after 90 seconds. The timeout is different between all the different browsers. What if you wanted to customize the timeout of a fetch request? Well, you could do that by passing the signal option to fetch along with the abort signal dot timeout function.
This accepts a number of milliseconds that you want to await before timing out the request. If I hit save now and I'll refresh the page, Sure enough, after about a second, we get the message in the console that appears in the catch block. So that's how you can customize the timeout of a fetch request. But there's more about this example that I want you to understand, namely that this is a network level error.
Another way I could trigger a network level error is by turning off my Wi-Fi. Then I'll refresh my page. Yeah, here I get an error, internet disconnected error. And once again, my catch block does run.
Now, the issue that I see people have with this is that they expect this same behavior with a request that actually successfully makes it to a server, but then sends back a status code other than 200. Let's take a look at an example of that. org, which is a great tool for testing different types of responses. And here I'm telling it to return a 404 response.
This is a not found response. This is not a 200 range response that you would consider successful. So you would expect that the catch block would run. Well, let's save this and see what happens in the browser.
Okay, I've got the aborted 404. Let me refresh the page for good measure. Same thing, but I don't see my console log from inside of the catch block. That's because our network connection was successful.
Even though we received a non-200 range status code from our server, we still connected with the remote server. If you want the catch block to run for a bad status code, what you would have to do is check the OK property on the response. Then if it's not OK, then you would have to throw your own error to trigger the catch. This time you see the code in our catch block ran.
So this is a very important thing to keep in mind when error handling with fetch. It's a mistake I've made many times in my career. Just make sure you remember that only network errors will trigger the catch of a fetch request. If you care about the status code from the fetch request, which most often times you should, then you will have to check the OK property on the response.
OK, another thing to keep in mind when error handling with fetch requests. is that sometimes the best course of action is not to just immediately show the user a failed message on a failed request. Sometimes in order to mitigate temporary downtime with API servers, it's nice to try the fetch request multiple times in order to give it the opportunity to respond successfully in a subsequent try. So that's exactly what this function here does.
It's called fetch with retry. It takes a URL and then a number of attempts to try before ultimately failing the request. How does it work? Well, it says while the attempts are greater than zero, if the request isn't successful, then throw an error.
And on catch of that unsuccessful request, decrement the number of attempts that are left, which means that the loop will run again. It will retry the request again. And then ultimately, if the number of attempts run out, then we throw an error to be caught in the code that runs this function. Let's take a look at using this down here inside of this try catch block.
org, but with the status possibilities of 200 or 500. HTTBin will respond randomly with either of these two status code responses. I'll save. Nice.
This time you see that the request ran three times and it received a 500 error code back each time, ultimately causing our catch block to run. Let's reload the page though. and see if this time it picks the 200 status code. And it looks like it does.
I have absolutely nothing logged to the console. Just to double check ourselves, let's run a little console log after the try catch is completed. Okay, give the page a refresh. You see that we do get a single request failed, but the subsequent retry is successful.
And so we make it to the end of the script without the catch block running. In this lesson, you learned that try catch will properly catch errors in the catch block for network level errors, that you can customize the timeout on your fetch request in order to control how long you allow them to attempt to connect before ultimately failing and triggering the catch. ok property. And then finally you saw an alternative approach to immediately notifying the user of a failed fetch request.
That is, retrying the fetch request automatically for a set number of attempts. If you'd like for an even more intuitive way of making fetch requests besides the native browser fetch function, then I suggest you check out this library called OFetch from the UnJS organization. It is a simple wrapper around the fetch function, but it includes support out of the box for a couple of features that we manually had to code out during this lesson. ok is false, meaning that you don't have to make that distinction between network errors and bad status codes.
It also includes support for auto retries. And it's a little bit smarter than our solution because it takes the status codes into account that are more often associated with temporary server issues. And it gives you some simple configuration options in order to control the retries. Same thing for setting the timeout.
And it has some other cool features too based on common needs and conventions that will... Take your breath away.