All right.
Let's go ahead.
We're gonna get started by first writing out our ear handling middleware inside of our project.
So I got to go back over to my editor.
I'm going to find my SDR C directory and inside there I'm gonna make a new folder called middleware
as well then create a new file inside of that directory called Air dash HANDLER Yes it's inside of here
we're gonna write out our error handling middleware.
Remember the only requirement is that it has to be a function that receives four arguments and the order
those arguments are the air request response.
And the next function showing what you write out and export a single function called air handler.
This is going to receive arguments of air rec.
RAZ And next we need to make sure that we apply some type annotations because right now typescript has
no idea what these arguments are supposed to be.
The first argument of error is always going to be some kind of actual air object.
So this will be like an error that gets thrown by some code that we write then wreck resin next are
going to be the request object response.
And the next function to apply some annotations to those we will import the request type response type
in next function type from Express at the top of the file.
So I will import requests response and next function from Express and then I will apply those types
to those arguments.
The request response and next function and I'll save it.
So it wraps that code down then inside of here.
Our job is to take a look at the air that just occurred.
We're then going to somehow format all the information inside there and respond back to whoever made
the request through this rez object.
The number one goal inside this air handler is to make sure that we always send back a very consistently
structured message because again we do not want our ReACT application to have to be trying to figure
out exactly how to handle all these 30 different kinds of errors.
We don't want to react to application to have to handle an array of objects or just a single string
or just an object.
We just want to have one single identical structure for all possible errors across all of our different
servers.
Right now let's just do a console log of the air itself we'll say a console log is something like something
went wrong and it will log the air out will then send back a response I'll give it a status of 400 and
I'll send a message that says something like something went wrong.
So ideally at some point in the future we're going to inspect this air we're gonna pull some information
out of it and then put it in this object or something like that.
This object right here.
That is what we want to have or make sure that we have a very consistent structure on.
Again it doesn't have to necessarily be an object.
It could be an array of objects whatever.
We'll figure that out at some point in time.
Now that we put together are air handling middleware we need to wired up to our Express application
to do so we'll go back over to our index dot test file right after all of our different routes.
I will import that error handler from middle where's error handler.
And then we will wire this up after all of our different route handlers.
So after app use we'll put down one more app use with air handler like so okay.
So this looks good.
Let's now close this file.
I'm going to close air handler and go back over to sign up dot t yes now at this point.
Time we are not actually throwing any errors inside of our code whatsoever instead.
If something goes wrong or if we find an error with this validation result right here we are automatically
sending back a status code of 400 along with that list of errors.
So in order to make sure that we have a very consistently structured response no matter what.
Rather than manually writing in some error handling code like this right here anytime something goes
wrong we're going to instead just throw an error.
So I'm going to throw a new air and as the reason for it I'll put in something like invalid email or
password will eventually actually consume that list of errors and get some more detailed information
about what is going on.
But for right now I just want to give you a general demonstration of what we're going to be doing.
Anytime something goes wrong inside of our code or in processing requests we are going to throw in air
and it's going to be automatically picked up by that air handler middleware that we just put together.
Now we can imagine let's just use our imagination for a moment.
Down here we've got a console log that says creating a user and maybe we attempt to save a user to our
database.
Let's imagine for a second that our database is always down 100 percent of the time.
Maybe we just have a really bad database connection so rather than actually successfully creating a
user.
Let's imagine that we throw an air right here and the air says something like air connecting to database
obviously we're not always going to have something like this.
We're just going to assume right now that for some reason our database is always down.
Now we're kind of in that scenario that we looked at just a moment ago in this diagram right here.
We might get past the point of checking to see if a e mail is valid but we are not able to access our
database and see if the e-mails are already in use.
Or maybe you even are in this scenario where we did check to see if the e-mail is already in use.
We try to create the user but the database is down.
So we now have multiple places where our code can fail multiple places where we can throw errors and
no matter what we are always capturing those errors.
Thanks to the fact that Express is going to automatically capture any air that we throw inside of a
root handler and throw it off to our area handling middleware where we can do some processing on it
let's now save this.
Test it out inside a postman and see how we're doing.
I'm going to go back over to postman inside a post man you'll notice that I have a invalid e-mail loaded
in here.
I'm going to send this request out and you'll see that I get back a response with a status of 400 and
a message of something went wrong now even if I enter in a valid email I still get the same thing.
So in the first case I got an error because I put in an invalid input so the data that I provided into
the request was not valid.
And so I got back an error message that said something went wrong when I entered in a valid e-mail I
got past the step where we were checking with Express validator.
So for the first request we were in scenario 1 when I put in a valid e-mail.
We are now in scenario number two where we can imagine that we got past the step where we go through
express validator and we are on to checking to see if that e mail is already in use.
Or maybe we try to create the user whatever else.
The point is we got past express validator and we were throwing an error now from some other cause or
some other reason inside our application.
And in both scenarios in scenario one and number two where we had a valid or invalid e-mail we always
got back a very consistent looking response right here and that's the key.
That's what we are after.
We want to make sure we always have a very consistent response at this point it might seem like I'm
still making a real big deal over stuff that is not challenging or not important.
So as I mentioned there are a couple of corner cases in here and kind of strange things and some really
big optimizations so we can throw in.
So we're not quite done yet.
Let's take a pause right here and continue in just a moment.