Now we improved the user experience
and we are handling the case that we don't have any comments
for a given post.
This could be considered an error,
but I actually also wanna handle real errors
where something goes wrong on the server.
We're not able to reach the database
or anything like this,
because such things, such problems can always occur,
and you should always plan for their occurrence.
And to simulate this,
let's go back to blog.js,
so to the server-side code here.
And there, let's say that we comment out this code
that should actually run,
and instead, I return a response
where I set the status code to 500
and I then return some JSON message where I say, "Error!"
Something like this.
Of course, this is now some code I wrote myself,
but I'm just writing this here to simulate
that this crashes for whatever reason
so that this is actually returning a response
but a response with a 500 status code,
and we wanna handle that as well.
For this, back in comments.js,
in the saveComment function
where we do send a request to that route
which does now return that 500 status code.
There, we now wanna handle that case
that we get a nonsuccess code.
And for this, on this response which we get,
we have this special ok field.
This will be true if we got a 200 response code,
which is a success HTTP status code.
Remember, these HTTP status codes,
I mentioned them earlier.
If you have a 200, or 201,
or 300-ish code, it's a success.
If you have a 400-ish or a 500-ish code,
it's an error.
So 500 is an error.
You got a response, but something went wrong on the server.
And in that case, ok would be false if you got such a 500
or 400-ish code.
So here we can actually check,
if response.ok is true, and only if it is true,
I wanna fetch my comments.
Else, we might want to show a message to the user,
maybe just with the good old built-in alert function
where we just say, "Could not send comment!"
Of course, you could also manipulate the DOM
to show some error message directly on the page.
You could add a new element,
add an overlay, whatever you wanna do.
Here, I'll just use this good old built-in alert.
And therefore, now with this if we go back and we reload,
and I try to send a comment,
this will fail because we changed the server-side code.
And hence, if I click here, I get this alert eventually.
So now we're also handling the case that things go wrong.
Now that's just one way of things going wrong though,
a very common way, hopefully not too common
but definitely something that could occur,
that things go wrong on the server.
But another error that could occur
is that the request is not even sent
because maybe the user is visiting this page
from a mobile phone and the connectivity is lost
whilst the user is on this page.
So in that case, sending the request might already fail.
It's not the response that has a status code of 500 or 400,
instead the request didn't even reach the server,
and we might wanna handle such a scenario as well.
In such a case that the request fails
for a technical reason,
so that we don't have a 400 or 500 status code
but a technical problem,
this fetch function will throw an error.
And you might recall that in an earlier course section,
I did talk about handling errors
that are thrown by some function.
We could do this with try/catch when using async/await.
We can try executing this code here
and catch an error if it fails,
so if it throws an error.
We also might want to move this code,
this if/else block into the try block,
because this should actually also only execute
if we do have a response at least.
So we try this code,
but if it fails, if we got a technical error,
for example, because the request isn't even sent,
then we also might want to show an alert
and say, "Could not send request - maybe try again later!"
or anything like that.
So now that's an error message
which we show in such a technical problem scenario.
Now to simulate this, I'll go back to the DevTools here,
and there in the Network tab,
I can actually go to this drop down here and choose offline.
Now the browser will simulate that I'm offline.
Actually, first of all, I'll go back to no throttling
and reload this page to load the updated JavaScript code,
and then I'll go to offline and now test this.
And now, here I get
"Could not send request - maybe try again later!"
So now I get this different error message,
because now we have a technical error
with sending the request.
If I'm online, if I have no throttling here,
then I get the other error, that server-side error,
which we're handling.
And you wanna handle both errors,
because both things could go wrong.
And therefore, of course,
you don't just wanna handle them here for sending a post,
but also for fetching comments.
Here you also want to check if you got a response
before you continue with parsing it
and outputting something on the page.
So here we could check if response.ok is false
by adding an exclamation mark in front of it,
and if that's the case,
I'll return so that the other code
won't even execute in this case
and also show an alert where I say,
"Fetching comments failed!" like this.
So with this block added,
we ensure that we don't continue
and we show this error
if something goes wrong on the server.
Still, we might also wanna handle technical errors.
And for this, we can wrap this all into a try block.
So take all that code and move that into try
and then just catch any technical errors that might occur
and say "Getting comments failed!"
or anything like that.
Now here, we could again simulate that this fails,
but I did already do that for sending comments,
so I'll not do it again here.
But still, you might wanna keep that in mind,
and you might wanna add error handling like this
for server-side errors and for technical errors
when you are working with Ajax requests,
because that allows you to provide a better user experience
when things go wrong.