In this lecture, we're gonna learn how error handling
works with a sinc/await.
So with a sinc/await, we can't use the catch method
that we use before, because we can really
attach it anywhere, right.
So instead, we use something called a try catch statement.
And the try catch statement is actually used
in regular JavaScript as well.
So it's been in the language probably since the beginning.
So try catch has nothing to do with a sinc/await.
But we can still use it to catch errors in async functions.
But before we do that, let's look at a more simple example,
just to see how try catch works.
So we can basically wrap all our code in a try block.
And so JavaScript will then
basically try to execute this code.
So just as normal code, so let's just create
a variable here, set it to one, create another one.
So this one is a constant.
And now my goal was to reassign y, but I will accidentally,
let's say reassign x.
And so that should then give us an error.
Because of course, that is not legal.
So we can reassign a constant.
And so for now, if we reload at this point,
first, we get this error,
that we are missing the catch block.
So let's actually first do this here without any block.
And so here, of course, we get the error assignment
to constant variable. Right.
But let's go back. And so now here,
we can add the catch block.
So we have a catch block, and this catch block
will have access to whatever error
occurred here in the try block.
And so now we can do something with this error.
So let's say we simply want to alert the error,
or just the error message.
So as we know, any error has the message property.
And so we can simply alert that one. So let's see.
And indeed, now we get an assignment
to constant variable here in this alert.
And you see that the error now no longer
appears down here in the console.
So the script does no longer die in this case.
And instead, we can simply catch the error right here,
and then handle it accordingly. Now, okay.
And of course, if there is no error at all,
so if I was assigning y correctly,
then we would get no error.
Well, at least not coming from the try catch block.
So now we're good.
But anyway, this year is just a stupid syntax error.
And of course, we're not going to use try catch
to find mistakes that we make in our code.
And so let's know use try catch for something more useful,
which is to actually handle real errors in async functions.
Okay. So just like in the small example that we saw,
let's wrap our entire code of this function
into a try block. All right,
so curly braces, and then try like this.
All right, and then down here after that,
the catch block, which remember, has access
to whatever error occurs in the try block.
And so here in this catch block,
we can now handle any errors,
just like we did before in the catch method.
So let's log the error to the console.
Give it a safe year, just to format it a little bit better.
Now, right, and so you see that
the code still works the same.
But that's because we didn't cause any error yet.
But let's also now log the error message.
But let's now also render the error.
And so instead of going search that,
I will simply write some new error message.
So if something went wrong, then we had this emoji here.
And then again, the error dot message.
Okay, and so now let's try again,
to force an error here by reloading really fast.
Maybe the easiest way is to simply
call this function multiple times.
And now, and now you see, we get some nice errors here.
Well, they're not really so nice.
So let's see where they actually start.
Well, for some reason,
everything looks the same as before.
And that's, of course, secrets render error,
until it actually also add an emoji,
just so we can see that it's our own error,
or basically, that we are logging the error ourselves.
Okay.
So let's do this. Ah, here we go.
Whoa. So we get a lot of different errors here.
So that's a couple of times.
And so the reason for that is that we are calling
this function here multiple times,
and therefore we get multiple errors.
But the error that gets logged here to the console,
remember is the one that is coming because of this 404 error
that the country cannot be found. Okay.
So at this point, we do have some error handling.
So we are able to add the error here to the user interface.
But just like before, this error is not really meaningful,
because the fetch promise does not reject on a 404 error,
or on a 403 error, which was actually the original error,
which caused everything here to collapse. Right?
So again, the four three is because
we are doing too many requests to the reverse geocoding API.
But the solution is simple,
because it's exactly the same as before.
So all we have to do is to manually create an error.
And so that error will then be caught
here in the catch block. Right?
So let's do that. So right here. So basically,
immediately after this fetch,
and so just like before,
we can test for the okay property, remember.
So I'm not going to show that again here,
because we already saw it before.
So this response here will have the okay property.
And if dad is not set to true, well,
then we want to throw a new error.
So that's problem getting, let's see location, data.
Okay. And so this one basically handles
any error in this fetch.
And so now the same here.
So let's say that we come back with a real weird country,
from this fetch.
Now to then the second API
cannot find any country for that name.
And so here, let's just say problem getting country.
Now, for this first promise here, this one,
we do not need to throw an error manually,
because in the case that something goes wrong
with the geolocation, we already built our promise
so that it automatically rejects in that case.
And so in this case, we will then immediately get an error,
which will get caught in the catch block.
But as we already know, the same is not true
for the promise coming from fetch.
So that promise only gets rejected
when the user has no internet connection.
But in case of a four, three error, or a 404 error,
the fetch promise does not reject.
And so again, we do that manually, right here,
and also right here.
And so here, we already see that it worked.
So here, indeed, we got something went wrong
problem getting a location, and then again,
here, the same error.
So here, maybe we don't want all of this error message.
Let's just take this one out.
So that we just have the emoji,
and then the error message itself.
So the one that we defined here, and here.
All right.
So let's see if this triggers an error.
And yeah, for one of them, we now
have problem getting location data.
So an error triggered by this one. All right.
So that is the complete version now of this async function,
complete with a pretty robust error handling strategy.
So again, please never ignore handling errors,
especially when it comes to asynchronous code
like this one, because here,
there is always a lot of stuff that can go wrong.
And so our application needs to be ready to handle that.
Now, right? But with that being said,
in the next lecture, we're going to dive even deeper
into how async functions really work.
And so let's go there right away.