Okay.
Welcome to section six.
And in this section we're going to take a look at error handling.
As we have to accept that our users are not always going to be walking down the happy path.
And sometimes they may encounter a problem with our application, no matter what we do to prevent this
kind of thing from happening.
So coming up in this section, we're going to take a look at error handling and exceptions.
And the goal of this really is to centralize the exception handling.
And to do that we're going to make use of middleware inside dotnet.
We're also going to take a look at the different types of HTTP response errors that we can get from
our application.
And as part of this we're also going to handle the client side errors as well.
And we're going to do as much as possible to centralize the error handling on the client as well.
So really the idea is that we set it up once and then we don't need to worry about it whilst writing
the logic for the rest of our application.
That's the goal doesn't really work like that.
In reality, we'll still end up doing minor error handling depending on the situation.
But for the majority of the errors that we can get back from our API.
Will attempt to handle them in a central location.
And because we're using RTK query.
Then we have a central place where we can configure client side error handling.
And we'll also take a look at debugging our application in this section, as dotnet does come with an
excellent debugger in order to help us find and solve problems with our applications.
But the most common type of thing that we'll see from our API point of view is the exception.
And you may come across something like this in your logs.
And the crucial thing is, as horrible as this looks, it's really not that bad as long as you ignore
most of it and just focus your attention on the first few lines, pretend the rest of it doesn't exist,
because it's very rare that you need to go that deep into finding out what the problem is.
When you do have an exception, all of the important information is contained at the beginning of the
exception.
And if you take a look at this particular example, it's just a custom error message that we'll create
ourselves as part of this section.
It tells you what the error message is.
It tells you where it came from, in this case a controller called Buggy Controller, specifically in
the get server error method, and the exception was generated based on the code in line 37.
So your next port of call is to take a look at that line of code in that method, in that controller,
to see what it was doing at the time.
And from there, depending on the type of error that you've got, is typically very easy to solve the
problem.
So please don't panic when you see an exception.
Yes, they do look horrible, but no, they are not as bad as they look that I can promise you.
And once you've dealt with a few of them, you won't see the 3040 lines of exception stack trace code.
You'll just focus your attention on the first few lines.
Typically, that gives you the route to finding out what the problem is.
That's not 100% correct.
There will be some exceptions where you need to delve a bit deeper, but for the vast majority then
all you need to focus on at this stage is really just the first few lines.
So our goal of this is to set up our exception handling centrally, because I'd like to be able to send
back the information about the exception to the client so that we can also display something in the
user interface so the user knows something has gone wrong.
To achieve that, we're going to take a look at middleware.
Now middleware is located inside our Program.cs class.
We don't have much at the moment.
And what we are going to add is going to be exception handling middleware.
Now exception handling middleware always comes first in this list, the idea being that if an exception
happens with an HTTP request as it goes through the pipeline and encounters other middleware on its
journey through to our controller, and then back out through the pipeline to the client.
If at any point on its journey it encounters an exception, then that exception gets thrown back up
the middleware tree until it encounters something that can catch and handle the exception.
And that's the goal of our exception middleware.
So when it comes to the middleware pipeline, each piece of middleware in the pipeline can have some
logic on the way in.
And it can also have some logic on the way out.
And it's controlled by the invoke async method inside the middleware.
So each piece of middleware is responsible for calling next, which is going to pass on the request
to the next piece of middleware.
And then as the request comes back through the middleware pipeline, then it can process more logic
or simply pass it on the chain until it goes out in the HTTP response.
And the idea of the exception handling middleware is that we do use a try catch block inside here,
so that we do catch the exception.
If nothing else is handling the exception in the middleware pipeline, then it's going to get passed
back up to our exception handler.
And at that point we can handle that exception and do something with it, which is what we're going
to do in this section.
We're also going to take a look at HTTP error responses.
Some common responses that we'll see in a 200 range means everything is okay.
And we've seen a few 200 type of responses.
We've got the 200 okay, the 201 created and the 204 no content.
All of those are success HTTP responses, not errors.
And then we have the 300 range which deals with redirection.
Anything in the 400 range is considered a client side error a 400 bad request.
The 403 forbidden a 401 unauthorized A 404 not found.
These are all considered client side errors.
The user is not authenticated.
The user's tried to go to a location that doesn't exist.
The user is not allowed to do what they've tried to do, that kind of thing.
And then we've got a 500 range, which is our server errors.
And typically in our scenario we're going to see the 500 internal server exception.
And as I mentioned we'll attempt to deal with these type of HTTP error responses centrally in our client
as well.
So let's begin.