We've now got a working demonstration of how to create custom airs how to throw them from our different
root handlers how to capture them inside of our air handler and send back a very common response for
every different kind of air but we're not quite done yet.
I want to point out something not so great about the current implementation of our airy handling middleware.
Right now we are throwing our request validation error and the database felt connection error into that
area handling middleware and we've encoded inside there some very intricate knowledge of exactly how
to extract information from every kind of error that exists inside our application.
Now present that's just two errors so it's not that big a deal.
Well let's imagine some scenario down the line where maybe we have a lot of different things that can
go wrong inside of our application and we create a custom error for everything that can go wrong.
And so we end up with all these different custom errors like this.
If we travel down the same road that we're going down right now our error handily Middleware is going
to be grow to be absolutely gigantic.
We will have to encode some logic inside there to understand every possible error and understand how
to extract information from them to send down to a user making sure that they all follow the same kind
of a common response structure.
So right now if we continue down the same path we're going to end up with our area handling middleware
growing to be extremely extremely large.
How can we fix this.
Well we're going to kind of inverse or take the opposite of this relationship.
We're going to go back and revisit our request validation error and the database connection error.
We're going to add in a method to each of these called serialize error.
The goal of this method is to take all the information about the air so whatever fields failed validation
or some reason that we failed to connect to the database and we're going to return some array of objects
that follow this kind of common error structure right here.
So an array of objects that have that message that the string and a possibly a field that is a string
as well we're also going to make sure that all these different errors list a status code to send down
as well once we do this.
Our air handler Middleware is no longer going to have to understand how to precisely pass and somehow
interpret a request validation error.
Instead the error handling middleware can just verify to make sure that the incoming air is of type
request validation error or database connection error wants to make sure that's an error that it understands
it can then call that errors serialize their property and get back some very customized very well-formed
structure to describe what just went wrong and send that back to the user.
It can also refer to the errors status code to understand what status code to use inside the response
as well.
Once we start to follow this approach we can create as many air custom classes as we want.
We can make a billion of these different things all very custom in nature each one can have its own
special implementation and the error handling middle way Middleware is not going to grow in much complexity
because no matter what the areas we're always going to refer to the same kind of serialize their function
and the same status code property.
OK so then mind let's go back over to our Ed we're going to start to refactor database connection there
and our other one that's behind the scenes here.
Request validation one we're going to make sure that they both have a serialized error method and a
status code property as well.
We're going to make sure that the air handler uses those methods and those properties as opposed to
trying to generate this formatted error stuff on its own.
All right so let's first start off with how about database connection error.
Here it is right here
the inside of database connection error.
We're going to add in that serialize errors method and inside of here we're going to make sure that
we return this common air structure specifically.
I really just want to return the array of objects that have a message and the field we will still allow
our error Hendley middleware to create this actual object and assign the errors property to it so inside
of database connection error I've got serialize errors we're going to return an array of objects in
this case the object they're gonna create is very simple it's always going to be one single error object
that's going to list this reason as the message so we can say.
Message is this dot reason and then in addition I'm also going to assign a status code to this.
So we're going to say anytime a database connection error occurs let's give the response a status code
of five hundred.
Now in this case again I want to remind you that database connection error is very simplistic in nature.
Yes we don't really need to define the separate property of reason right here.
We could just take that string and throw it in as the message.
The only reason that we are reading this entire database connection air class is that you have a second
example to look at beyond just request validation error.
The other air class we created OK so that's it for this one.
I'm going to say this file will then go over to request validation error also inside of our ears directory
I'm going to give this one a status code as well.
Four hundred in this case and then I will give it that serialize heirs property
and we can really just take the code that we are already wrote out inside of our area handling middleware.
It's going to go backwards of the error handler.
You'll recall that we mapped over the errors and where each error.
We returned an object that a message and a field.
So we essentially want to do that same thing inside of this serialize errors.
Function right here I'm going to return the result of this dot errors dot map.
I'm going to take each error which I will abbreviate as you are and then return message with E R dot
message and a field with E R dot Ram OK.
So now are two errors both follow the same kind of structure.
They both had the serialized errors method and they both have status code.
So now back inside of our air handling middleware there it is right here.
We no longer have to encode all this fancy logic into this middleware so we can delete all that fancy
logic we can also do the same thing down here for the database connection error as well.
So we no longer have to encode this entire special array right here which is kind of assuming that we
have a lot of special knowledge about how database connection error works.
It's going to delete that to also formatted errors goes away up here because that variable doesn't exist
anymore.
Now in both cases we want to take a look at that incoming air and we're going to call these serialized
errors function on both them.
That's going to give us back that array of objects that we want so so badly apparently.
I'm definitely making it seem like it's a very desirable thing to have.
OK.
So in both cases we'll do ya dot serialize errors and then same thing down here as well
and that should be at you'll now notice that we have an identical statement here with both these f statements.
Once we have verified that we have either a request validation error or a database connection error
were then very sure that we pretty much always want to do the same thing of getting serialize errors.
One other thing that we want to take care of is the status codes on both as well.
So now our middleware doesn't need to know about the precise status code to use for any kind of error.
Instead it just knows to take a look at the errors status code property so and replace the 400 right
there with IRR status code and the 500 right here with ya dot status code as well all these definitely
look very identical in nature and as you can guess we're probably going to combine these two statements
at some point but right now let's just say this and do another quick test to make sure that everything
is still working as expected so back over at postmen I'm going to first try out the database connection
error stuff I can send that off you still get the correct error and if I put in an invalid email you
still get the rector as well.
All right.
So right away you can start to see that we are going to extract a lot of logic out of this area handling
middleware and we're going to delegate figuring out how to produce the correct structure of errors and
the quick status code in each error instead.
This is looking pretty good but we still have one or two very small improvements so quick pause right
here and I'll see you in just a minute.