All language subtitles for 007 Handling Http Errors_en

Now, when sending HTTP requests,

things can also go wrong, of course.

You can encounter errors,

both technical errors

because, for example, you have no network connection,

or you do have a network connection

and the request is sent

but you get back an error response code,

something like 404 or 500 or 401 codes.

And in case this doesn't tell you much,

attached you find this Wikipedia article

on the response codes which you commonly get

and for example, you will get a 200 or 201 code

or any 200-ish code if you had a successful response.

So you send the request

and the server was able to produce a successful response.

But when sending requests,

you also sometimes get 400 or 500 responses.

Now, for example, if you're sending a request

to a resource which you may not access

because you're not authorized,

something we'll talk about later in the course

when we talk about authentication,

then the request might be sent successfully,

there is no technical problem

but the server replies with a 401 or a 403 response,

making it clear that it got your request

but it doesn't want to give you the response you wanted.

So you then get a successful response technically

but it has an error character

because of this error status code,

which is attached to it.

And you could also be getting a 500-ish response

if there was some server error.

This is how the web works.

Now, I can simulate this here

if I try to send the request to swapi.dev/api/film

instead of films.

This is a invalid URL.

It's a REST endpoint which is not supported by this REST API

and hence, if we save this

and we send the request, we don't get back data.

It's stuck in the loading state,

which of course, is a bad user experience.

It would be better to show the user some error

so that the user of this applications knows

that things went wrong.

Now, if we open the developer tools,

we see an error here.

We got back a 404 response.

That's what I meant.

Technically, it was a successful request.

It left our machine,

was sent to a server and we got back a response

but the response has a 404 status code,

indicating that something's wrong with the response.

In this case, that we requested a resource the server

was not prepared for.

Now, as I said, we wanna handle such errors

and therefore, we might wanna introduce a third state here.

An error state with error and setError.

Now, initially, that might be null

because initially, we have no error.

And whenever fetchMoviesHandler is fired,

we also might wanna reset this error to null.

Like this to make sure that we clear any previous errors

we might have gotten.

But we wanna set it

to something else than null if we do get an error here.

Now, if we're not using async await,

if we work with then and so on,

then we would add catch to catch any errors.

Now, when working with async await,

we instead use try catch.

So we try some code and we catch any potential errors.

So here I wanna grab all of that

and move that into the try block

and then catch any potential errors

that might be caused by the code in the try block.

So now whenever some error is thrown here,

we will catch it.

Now, one problem we'll face here

is that the Fetch API doesn't treat error status codes

as real errors.

It will not throw a technical error

if we get back an error status code.

So the problem we have here

would not result in an error.

We would only get an error in a second step

if we then try to operate on data,

which we haven't gotten.

But that's not how we wanna handle this.

Instead, it would be better

if we would throw a real error

if we got back a response with an unsuccessful status code.

And again, by default, the Fetch API here

doesn't do that.

Axios, on the other hand,

this package I mentioned earlier,

this third-party library,

which you could use for sending requests,

would generate and throw a real error

for error status codes.

Now, since we're not using axios here

but the Fetch API, we have to do this on our own

and it is easy to do that.

I mentioned that the response object,

which we get back has this ok field,

which basically signals whether the response

was successful or not.

So we can check if response is not ok, like this,

and then generate and throw our own error in that case.

So here we can then throw a new Error

with some error message of our choice.

We could read an error message

from the error response we got back from the server

or use our own error message,

which is what I will do.

And I'll just say Something went wrong here.

Now we throw this error

if we have an unsuccessful response.

And since we throw an error here,

we, of course, won't continue with the next step in line.

Instead, we'll make it into this catch block

and here we can now call setError

and set this equal to error.message.

So now Error is a string.

It's this string here in this case to be precise.

And with that, we're managing this error state.

Now we also wanna, of course, output it down there.

We wanna output some content based

on whether we do have an error or not.

So we can again render something conditionally

and we can check if we're not loading,

because, of course, if we are loading,

we wanna wait what the result of that is.

But if we're not loading,

and we do have an error,

so if that is not null or undefined,

but if we do have an error,

then I wanna display this error.

So then I'll render a paragraph

with this error text inside of it, like this.

And I also, of course, wanna make sure

that we always stop loading.

Even if we have an error, we're not loading anymore.

So we also wanna setIsLoading to false here

or we simply move it after this try catch block

so that we always setIsLoading to false

no matter if we have a successful

or an error response

because either way, we're done loading.

And with that, if we save this,

if I click Fetch Movies,

we're loading and then I get some output here.

Found no movies and then my error message here.

Now, that's not the error message I'm setting here

because actually here I'm calling json on the response

and this already fails

because we're not getting back JSON data

for this request for this invalid API endpoint.

So actually I should check for the response being ok

before I even try to parse the response body.

Now, the exact way of handling the error response depends

on the API you're talking to.

Some APIs also send back JSON data

if the request was not successful.

Other APIs like this one send back non-JSON data,

so therefore, here we need to handle this before

we try to parse that.

With that though, if I now click Fetch Movies,

we see something went wrong.

I also see found no movies,

which, of course, is not what I want.

I wanna make sure that we only show this fallback text

if we're not loading, we've got no movies

and we've got no error.

So here I'll check that we have no error

in addition to the other checks.

And with that, if we now try this again,

then we have this state

and if I fix this error by adding the S again here,

and we now save this,

we, of course, can successfully fetch movies again.

And this is how we can handle all the different states

we might have when sending HTTP requests.

And this is important

because no matter to which backend app you're talking,

you will always have these different states.

You will always be waiting for the response,

you might always be getting errors,

you might always be getting back your data hopefully

and your data might always be empty,

at least in most cases it might be empty

and therefore, it's important that you know

how to handle these different scenarios.

Now, of course, instead of writing

all these inline checks here,

we could also write this more elegantly.

We could add a new variable, content,

which by default, let's say is Found no movies.

And then we set it to something else,

depending on which state we have.

So we can check if we're loading, for example,

in which case, we set content equal to Loading

or whatever you wanna display when you're loading.

Now, we can also check, before we check for loading,

because this should override everything,

so I check for it last,

before checking that,

we can check if we have an error.

If that is truth.

In that case, we can set content equal to error.

And of course, we might also have our data.

I mean, hopefully that is what we have in the end.

So we can check for that first.

We can check if movies.length

is greater than zero, in which case,

content should be equal to this MoviesList here.

So let's grab that.

And set content equal to that here.

And now we can replace all that inline output down there

with just rendering content, this content variable.

And the value stored in the content variable

will now differ based on the state we have.

It's either found no movies

or loading or our movies

or again, if I temporarily remove that S here,

like this, then it can also be that error message.

So that's how this works

and that's how we can handle these different states.