WEBVTT 00:00.000 --> 00:00.330 Okay. 00:00.330 --> 00:01.680 Welcome to section six. 00:01.680 --> 00:04.440 And in this section we're going to take a look at error handling. 00:04.440 --> 00:09.690 As we have to accept that our users are not always going to be walking down the happy path. 00:09.690 --> 00:16.500 And sometimes they may encounter a problem with our application, no matter what we do to prevent this 00:16.500 --> 00:18.060 kind of thing from happening. 00:18.060 --> 00:23.130 So coming up in this section, we're going to take a look at error handling and exceptions. 00:23.130 --> 00:27.240 And the goal of this really is to centralize the exception handling. 00:27.240 --> 00:31.350 And to do that we're going to make use of middleware inside dotnet. 00:31.380 --> 00:36.030 We're also going to take a look at the different types of HTTP response errors that we can get from 00:36.030 --> 00:37.170 our application. 00:37.170 --> 00:42.210 And as part of this we're also going to handle the client side errors as well. 00:42.210 --> 00:47.040 And we're going to do as much as possible to centralize the error handling on the client as well. 00:47.040 --> 00:53.970 So really the idea is that we set it up once and then we don't need to worry about it whilst writing 00:53.970 --> 00:56.190 the logic for the rest of our application. 00:56.190 --> 00:58.350 That's the goal doesn't really work like that. 00:58.350 --> 01:03.690 In reality, we'll still end up doing minor error handling depending on the situation. 01:03.690 --> 01:07.180 But for the majority of the errors that we can get back from our API. 01:07.210 --> 01:10.990 Will attempt to handle them in a central location. 01:10.990 --> 01:13.480 And because we're using RTK query. 01:13.510 --> 01:18.790 Then we have a central place where we can configure client side error handling. 01:18.790 --> 01:24.280 And we'll also take a look at debugging our application in this section, as dotnet does come with an 01:24.280 --> 01:29.260 excellent debugger in order to help us find and solve problems with our applications. 01:29.260 --> 01:35.140 But the most common type of thing that we'll see from our API point of view is the exception. 01:35.140 --> 01:38.950 And you may come across something like this in your logs. 01:38.950 --> 01:48.490 And the crucial thing is, as horrible as this looks, it's really not that bad as long as you ignore 01:48.520 --> 01:54.580 most of it and just focus your attention on the first few lines, pretend the rest of it doesn't exist, 01:54.580 --> 01:59.380 because it's very rare that you need to go that deep into finding out what the problem is. 01:59.380 --> 02:06.040 When you do have an exception, all of the important information is contained at the beginning of the 02:06.040 --> 02:06.730 exception. 02:06.730 --> 02:12.050 And if you take a look at this particular example, it's just a custom error message that we'll create 02:12.050 --> 02:14.390 ourselves as part of this section. 02:14.390 --> 02:16.910 It tells you what the error message is. 02:16.940 --> 02:23.030 It tells you where it came from, in this case a controller called Buggy Controller, specifically in 02:23.030 --> 02:30.410 the get server error method, and the exception was generated based on the code in line 37. 02:30.410 --> 02:36.110 So your next port of call is to take a look at that line of code in that method, in that controller, 02:36.110 --> 02:38.210 to see what it was doing at the time. 02:38.210 --> 02:43.880 And from there, depending on the type of error that you've got, is typically very easy to solve the 02:43.880 --> 02:44.330 problem. 02:44.360 --> 02:46.310 So please don't panic when you see an exception. 02:46.310 --> 02:51.290 Yes, they do look horrible, but no, they are not as bad as they look that I can promise you. 02:51.320 --> 02:57.710 And once you've dealt with a few of them, you won't see the 3040 lines of exception stack trace code. 02:57.710 --> 03:00.740 You'll just focus your attention on the first few lines. 03:00.740 --> 03:05.480 Typically, that gives you the route to finding out what the problem is. 03:05.510 --> 03:07.070 That's not 100% correct. 03:07.070 --> 03:11.830 There will be some exceptions where you need to delve a bit deeper, but for the vast majority then 03:11.830 --> 03:17.080 all you need to focus on at this stage is really just the first few lines. 03:17.740 --> 03:23.710 So our goal of this is to set up our exception handling centrally, because I'd like to be able to send 03:23.710 --> 03:28.960 back the information about the exception to the client so that we can also display something in the 03:28.960 --> 03:32.140 user interface so the user knows something has gone wrong. 03:32.170 --> 03:34.990 To achieve that, we're going to take a look at middleware. 03:35.020 --> 03:40.060 Now middleware is located inside our Program.cs class. 03:40.060 --> 03:42.310 We don't have much at the moment. 03:42.310 --> 03:47.680 And what we are going to add is going to be exception handling middleware. 03:48.730 --> 03:54.310 Now exception handling middleware always comes first in this list, the idea being that if an exception 03:54.310 --> 04:00.610 happens with an HTTP request as it goes through the pipeline and encounters other middleware on its 04:00.610 --> 04:04.840 journey through to our controller, and then back out through the pipeline to the client. 04:04.840 --> 04:10.930 If at any point on its journey it encounters an exception, then that exception gets thrown back up 04:10.930 --> 04:16.220 the middleware tree until it encounters something that can catch and handle the exception. 04:16.220 --> 04:18.710 And that's the goal of our exception middleware. 04:18.740 --> 04:25.130 So when it comes to the middleware pipeline, each piece of middleware in the pipeline can have some 04:25.130 --> 04:26.930 logic on the way in. 04:27.590 --> 04:30.530 And it can also have some logic on the way out. 04:30.530 --> 04:35.030 And it's controlled by the invoke async method inside the middleware. 04:35.030 --> 04:40.340 So each piece of middleware is responsible for calling next, which is going to pass on the request 04:40.370 --> 04:41.930 to the next piece of middleware. 04:41.930 --> 04:46.610 And then as the request comes back through the middleware pipeline, then it can process more logic 04:46.610 --> 04:52.700 or simply pass it on the chain until it goes out in the HTTP response. 04:52.700 --> 04:58.610 And the idea of the exception handling middleware is that we do use a try catch block inside here, 04:58.610 --> 05:00.170 so that we do catch the exception. 05:00.170 --> 05:05.210 If nothing else is handling the exception in the middleware pipeline, then it's going to get passed 05:05.210 --> 05:06.800 back up to our exception handler. 05:06.800 --> 05:12.650 And at that point we can handle that exception and do something with it, which is what we're going 05:12.680 --> 05:15.230 to do in this section. 05:15.230 --> 05:18.420 We're also going to take a look at HTTP error responses. 05:18.420 --> 05:23.700 Some common responses that we'll see in a 200 range means everything is okay. 05:23.730 --> 05:26.430 And we've seen a few 200 type of responses. 05:26.430 --> 05:31.080 We've got the 200 okay, the 201 created and the 204 no content. 05:31.080 --> 05:35.520 All of those are success HTTP responses, not errors. 05:35.520 --> 05:39.360 And then we have the 300 range which deals with redirection. 05:39.360 --> 05:44.340 Anything in the 400 range is considered a client side error a 400 bad request. 05:44.370 --> 05:49.230 The 403 forbidden a 401 unauthorized A 404 not found. 05:49.260 --> 05:51.510 These are all considered client side errors. 05:51.540 --> 05:53.490 The user is not authenticated. 05:53.490 --> 05:56.970 The user's tried to go to a location that doesn't exist. 05:56.970 --> 06:00.870 The user is not allowed to do what they've tried to do, that kind of thing. 06:00.870 --> 06:04.230 And then we've got a 500 range, which is our server errors. 06:04.230 --> 06:10.590 And typically in our scenario we're going to see the 500 internal server exception. 06:10.590 --> 06:17.370 And as I mentioned we'll attempt to deal with these type of HTTP error responses centrally in our client 06:17.370 --> 06:18.720 as well. 06:18.720 --> 06:20.340 So let's begin.