When making requests to API endpoints, it's inevitable that you're going to have error responses. It just happens the API servers fail for one reason or another, and you have to be prepared to handle those errors. So in this lesson, I have stripped back our users page to basically nothing. We had the use fetch being called here still.
But now we're making a request to an internal slash API slash error endpoint. We're still doing the non-blocking kind of navigation. And then down inside of the template, I have just the data printed out to the page and a button that calls the execute function to initiate the request again. Okay, what is this slash API slash error API endpoint doing?
Right now, it's just returning a 200 response and some data with a request of that being equal to the current date timestamp. Okay, so in the browser, we get exactly this. What if I were to return a 404 or a 500 or any non-200 range status code? Well, let's try 404.
Go back to my page now, hit refresh, and you'll notice I just don't get the data. I don't have a error page showing that there was a 404, but in a lot of cases, that's probably what you want to do. If this 404 was coming from a blog post someone was attempting to visit that just did not exist, then we would want to show a 404 page here. So back in the code, we need to destructure error from useFetch.
Now, error is a reactive ref. value. Okay, so if the error exists, then we want to show a full page 404 error. So the way we do that in Nuxt is to throw the create error function.
What do I want this error to look like? Well, I do want it to be a fatal error. That is, I want it to trigger the full page to go into that. error page mode.
So this will be true. value into this object so that it inherits the same status and message and all that. So now back in the browser, sure enough, I do get a 404 error page. This is great.
So this works fine. So you might think, well, this is the solution to handling your errors. Well, not so fast. Let's change the response here back to 200.
Go back to my page, refresh, and of course we get the page displaying as it should. If I go to execute the request again with refresh data, we do get the data back. However, let's say that my server fails and now it sends a 404, or actually it probably should be a 500 if it just randomly fails. Now, when I hit refresh data, you would expect the error page to show.
Well, does it? Hit refresh data, and no, my data just disappears on the page. There's no real indication to the user what actually went wrong. value directly inside of script setup, a better way to do that is to do it inside of a watch effect.
All right? So this watch effect is going to run any time the value of error changes, because that's just how watch effect works. Let me reformat things here just a little bit. Looks like ESLint isn't working for me, but that is okay.
Okay. So now this will run immediately on page load, but it'll also run if error changes at any point during the lifespan of my page, such as when a user clicks refresh data. Let's give it a try now. So I'll refresh my page.
We do indeed get a 500 error page here, which is great. So the watch effect works on page load with an error. But let me change this back to 200. So our initial page load works as expected, but then for some reason, our server is going to fail later on.
Now, if I hit refresh data, we do indeed get the error page. So if you want to show a full error page anytime your request fails, then you want to go for watch effect. Of course, depending on your use case, you might not always want to display a full page error. But this is the mistake I see people making most often, and I myself have made plenty of times before as well, thinking that the condition at the root of script setup without watch effect covers all my bases for the full page error, when really it doesn't.