1
00:00:01,710 --> 00:00:02,070
All right.

2
00:00:02,070 --> 00:00:02,700
Let's go ahead.

3
00:00:02,700 --> 00:00:07,060
We're gonna get started by first writing out our ear handling middleware inside of our project.

4
00:00:07,140 --> 00:00:09,180
So I got to go back over to my editor.

5
00:00:09,390 --> 00:00:14,370
I'm going to find my SDR C directory and inside there I'm gonna make a new folder called middleware

6
00:00:14,370 --> 00:00:23,550
as well then create a new file inside of that directory called Air dash HANDLER Yes it's inside of here

7
00:00:23,570 --> 00:00:25,550
we're gonna write out our error handling middleware.

8
00:00:25,610 --> 00:00:30,170
Remember the only requirement is that it has to be a function that receives four arguments and the order

9
00:00:30,170 --> 00:00:32,710
those arguments are the air request response.

10
00:00:32,720 --> 00:00:43,650
And the next function showing what you write out and export a single function called air handler.

11
00:00:43,710 --> 00:00:46,990
This is going to receive arguments of air rec.

12
00:00:47,140 --> 00:00:52,620
RAZ And next we need to make sure that we apply some type annotations because right now typescript has

13
00:00:52,620 --> 00:00:55,010
no idea what these arguments are supposed to be.

14
00:00:55,110 --> 00:00:59,910
The first argument of error is always going to be some kind of actual air object.

15
00:00:59,910 --> 00:01:06,350
So this will be like an error that gets thrown by some code that we write then wreck resin next are

16
00:01:06,350 --> 00:01:08,020
going to be the request object response.

17
00:01:08,030 --> 00:01:14,480
And the next function to apply some annotations to those we will import the request type response type

18
00:01:14,480 --> 00:01:17,770
in next function type from Express at the top of the file.

19
00:01:17,990 --> 00:01:26,270
So I will import requests response and next function from Express and then I will apply those types

20
00:01:26,450 --> 00:01:27,980
to those arguments.

21
00:01:27,980 --> 00:01:32,910
The request response and next function and I'll save it.

22
00:01:32,910 --> 00:01:37,370
So it wraps that code down then inside of here.

23
00:01:37,380 --> 00:01:40,610
Our job is to take a look at the air that just occurred.

24
00:01:40,680 --> 00:01:45,570
We're then going to somehow format all the information inside there and respond back to whoever made

25
00:01:45,570 --> 00:01:47,760
the request through this rez object.

26
00:01:47,760 --> 00:01:53,130
The number one goal inside this air handler is to make sure that we always send back a very consistently

27
00:01:53,130 --> 00:01:58,830
structured message because again we do not want our ReACT application to have to be trying to figure

28
00:01:58,830 --> 00:02:03,310
out exactly how to handle all these 30 different kinds of errors.

29
00:02:03,330 --> 00:02:08,220
We don't want to react to application to have to handle an array of objects or just a single string

30
00:02:08,460 --> 00:02:09,650
or just an object.

31
00:02:09,660 --> 00:02:14,940
We just want to have one single identical structure for all possible errors across all of our different

32
00:02:14,940 --> 00:02:16,740
servers.

33
00:02:16,820 --> 00:02:22,580
Right now let's just do a console log of the air itself we'll say a console log is something like something

34
00:02:23,120 --> 00:02:35,510
went wrong and it will log the air out will then send back a response I'll give it a status of 400 and

35
00:02:35,510 --> 00:02:41,210
I'll send a message that says something like something went wrong.

36
00:02:41,210 --> 00:02:45,680
So ideally at some point in the future we're going to inspect this air we're gonna pull some information

37
00:02:45,680 --> 00:02:49,120
out of it and then put it in this object or something like that.

38
00:02:49,250 --> 00:02:50,100
This object right here.

39
00:02:50,120 --> 00:02:54,470
That is what we want to have or make sure that we have a very consistent structure on.

40
00:02:54,560 --> 00:02:56,930
Again it doesn't have to necessarily be an object.

41
00:02:56,990 --> 00:02:58,870
It could be an array of objects whatever.

42
00:02:58,880 --> 00:03:00,490
We'll figure that out at some point in time.

43
00:03:03,230 --> 00:03:07,580
Now that we put together are air handling middleware we need to wired up to our Express application

44
00:03:08,150 --> 00:03:13,320
to do so we'll go back over to our index dot test file right after all of our different routes.

45
00:03:13,340 --> 00:03:20,630
I will import that error handler from middle where's error handler.

46
00:03:20,630 --> 00:03:24,530
And then we will wire this up after all of our different route handlers.

47
00:03:24,570 --> 00:03:33,270
So after app use we'll put down one more app use with air handler like so okay.

48
00:03:33,320 --> 00:03:34,010
So this looks good.

49
00:03:35,360 --> 00:03:36,850
Let's now close this file.

50
00:03:36,890 --> 00:03:41,750
I'm going to close air handler and go back over to sign up dot t yes now at this point.

51
00:03:41,750 --> 00:03:47,600
Time we are not actually throwing any errors inside of our code whatsoever instead.

52
00:03:47,850 --> 00:03:53,160
If something goes wrong or if we find an error with this validation result right here we are automatically

53
00:03:53,160 --> 00:03:57,650
sending back a status code of 400 along with that list of errors.

54
00:03:57,720 --> 00:04:02,430
So in order to make sure that we have a very consistently structured response no matter what.

55
00:04:02,430 --> 00:04:06,810
Rather than manually writing in some error handling code like this right here anytime something goes

56
00:04:06,810 --> 00:04:10,250
wrong we're going to instead just throw an error.

57
00:04:10,300 --> 00:04:19,040
So I'm going to throw a new air and as the reason for it I'll put in something like invalid email or

58
00:04:19,070 --> 00:04:24,690
password will eventually actually consume that list of errors and get some more detailed information

59
00:04:24,690 --> 00:04:25,680
about what is going on.

60
00:04:25,710 --> 00:04:29,290
But for right now I just want to give you a general demonstration of what we're going to be doing.

61
00:04:29,290 --> 00:04:34,440
Anytime something goes wrong inside of our code or in processing requests we are going to throw in air

62
00:04:34,710 --> 00:04:39,960
and it's going to be automatically picked up by that air handler middleware that we just put together.

63
00:04:40,060 --> 00:04:43,150
Now we can imagine let's just use our imagination for a moment.

64
00:04:43,480 --> 00:04:47,830
Down here we've got a console log that says creating a user and maybe we attempt to save a user to our

65
00:04:47,830 --> 00:04:49,160
database.

66
00:04:49,210 --> 00:04:53,740
Let's imagine for a second that our database is always down 100 percent of the time.

67
00:04:53,770 --> 00:04:59,490
Maybe we just have a really bad database connection so rather than actually successfully creating a

68
00:04:59,490 --> 00:04:59,830
user.

69
00:04:59,850 --> 00:05:06,900
Let's imagine that we throw an air right here and the air says something like air connecting to database

70
00:05:10,060 --> 00:05:11,970
obviously we're not always going to have something like this.

71
00:05:11,970 --> 00:05:16,390
We're just going to assume right now that for some reason our database is always down.

72
00:05:16,420 --> 00:05:21,570
Now we're kind of in that scenario that we looked at just a moment ago in this diagram right here.

73
00:05:21,730 --> 00:05:27,220
We might get past the point of checking to see if a e mail is valid but we are not able to access our

74
00:05:27,220 --> 00:05:29,380
database and see if the e-mails are already in use.

75
00:05:29,380 --> 00:05:33,190
Or maybe you even are in this scenario where we did check to see if the e-mail is already in use.

76
00:05:33,190 --> 00:05:36,060
We try to create the user but the database is down.

77
00:05:36,160 --> 00:05:41,520
So we now have multiple places where our code can fail multiple places where we can throw errors and

78
00:05:41,590 --> 00:05:44,310
no matter what we are always capturing those errors.

79
00:05:44,530 --> 00:05:49,420
Thanks to the fact that Express is going to automatically capture any air that we throw inside of a

80
00:05:49,420 --> 00:05:53,800
root handler and throw it off to our area handling middleware where we can do some processing on it

81
00:05:54,920 --> 00:05:56,090
let's now save this.

82
00:05:56,090 --> 00:06:00,120
Test it out inside a postman and see how we're doing.

83
00:06:00,190 --> 00:06:05,610
I'm going to go back over to postman inside a post man you'll notice that I have a invalid e-mail loaded

84
00:06:05,610 --> 00:06:06,390
in here.

85
00:06:06,540 --> 00:06:11,610
I'm going to send this request out and you'll see that I get back a response with a status of 400 and

86
00:06:11,610 --> 00:06:20,390
a message of something went wrong now even if I enter in a valid email I still get the same thing.

87
00:06:20,400 --> 00:06:26,550
So in the first case I got an error because I put in an invalid input so the data that I provided into

88
00:06:26,550 --> 00:06:28,040
the request was not valid.

89
00:06:28,410 --> 00:06:34,530
And so I got back an error message that said something went wrong when I entered in a valid e-mail I

90
00:06:34,530 --> 00:06:40,770
got past the step where we were checking with Express validator.

91
00:06:40,770 --> 00:06:45,150
So for the first request we were in scenario 1 when I put in a valid e-mail.

92
00:06:45,170 --> 00:06:50,250
We are now in scenario number two where we can imagine that we got past the step where we go through

93
00:06:50,250 --> 00:06:54,150
express validator and we are on to checking to see if that e mail is already in use.

94
00:06:54,150 --> 00:06:56,740
Or maybe we try to create the user whatever else.

95
00:06:56,880 --> 00:07:02,550
The point is we got past express validator and we were throwing an error now from some other cause or

96
00:07:02,550 --> 00:07:04,740
some other reason inside our application.

97
00:07:04,950 --> 00:07:09,930
And in both scenarios in scenario one and number two where we had a valid or invalid e-mail we always

98
00:07:09,930 --> 00:07:14,250
got back a very consistent looking response right here and that's the key.

99
00:07:14,250 --> 00:07:15,460
That's what we are after.

100
00:07:15,510 --> 00:07:21,060
We want to make sure we always have a very consistent response at this point it might seem like I'm

101
00:07:21,060 --> 00:07:27,010
still making a real big deal over stuff that is not challenging or not important.

102
00:07:27,030 --> 00:07:31,410
So as I mentioned there are a couple of corner cases in here and kind of strange things and some really

103
00:07:31,410 --> 00:07:33,760
big optimizations so we can throw in.

104
00:07:33,760 --> 00:07:34,860
So we're not quite done yet.

105
00:07:35,130 --> 00:07:37,620
Let's take a pause right here and continue in just a moment.