All right.
Let's get to it.
We're going to start to build out these subclasses of request validation error and database connection
error as we are building into two classes.
There's going to be a little bit of strange code.
We're going to mostly just kind of blaze through these two implementations because as soon as we start
using them you are going to understand what is going on as we're building them.
You're going to say wait what.
But don't worry as soon as we use them it's going to be really clear.
OK.
Let's get to it.
Back inside my editor are going to find my SRT directory and inside there are gonna make a new folder
called ears inside this directory we're gonna write out all these different custom subclasses of air
so the first one I'm going to make is request validation error Dot T S
then at the very top I'm going to first import validation air from Express dash validator validation
error is a type it is describing the type that comes back whenever we do a validation attempt using
express validator.
So it's essentially a type that refers to this kind of object right here.
Something has a message a param also technically a field and one of the property I can't remember off
the top my head.
The reason that we are importing this is that when we start to build a subclass at some point time we're
going to have to receive a list of validation errors like in other words the actual reasons that the
request failed validation so we are importing this type to make sure that we can describe the requirements
or the so we're going to be assigned to our subclass after that.
I'm going to export a new class called request validation error and we're going to extend.
So again we are building our own custom implementation of an error been inside of here going to define
the constructor function I'm going to say that this is going to need to be called with a list of validation
errors.
So again that is why we import this type at the very top so I to write out right here private errors
is going to be validation error.
Right let's break this down really quickly.
I'm using the keyword private right here because we want to take this first property and assign it as
a property to the overall class.
So writing out the word private right there is 100 percent equivalent to writing this dot errors equal
errors and then also defining this property ahead of time though something like validation error.
So what you see right here is a hundred percent equivalent to just writing out private errors.
Now I still have an error around the constructor as because we are extending a base class whenever we
do so and we defined a constructor we have to call super to invoke the constructor inside the base class
which in this case is air.
So I will call super to fix that
now one word very small thing.
This is a very small technicality.
It only has to be done when we are writing TypeScript and trying to extend a class that is built in
to language.
So we are trying to extend it right here which is built into the language to do so.
We have to write out one additional line of code right here.
I'm going to put it a little quick comment that says only because we are extending a built in class
we will write out the object that set prototype of and then this and request validation error.
That prototype but this is just some behind the scenes stuff that gets our class to work correctly.
Again just because we are extending a built in class OK.
So now how would we use this class right here.
Well we would say something like new request validation error and then we would pass in the list of
errors like so we would probably want to throw this as well because it is intended to be an error.
And then this thing this instance that we are creating and throwing again should be communicated automatically
down so that's like that error right there it should be communicated down into our error handling middleware
now there is one other quick change I'm going to make here.
I'm actually gonna update this keyword of private over to public.
We eventually are going to reverted back to private.
I was reading my notes here looking at the final implementation.
We're gonna leave it as public for just a moment.
We were gonna flip that back over to private and just a little bit OK.
So we've now got our first custom air put together let's build our other custom air out which is going
to be called database connection air that's gonna be very similar in nature but it's gonna have this
reason property that's gonna be a string instead of reasons that's going to be an array of validation
errors inside of my ears folder I'm going to create another file called database connection air dot
T.S. and then inside of here we're going to do something very similar.
So we will export a new class called database connection air stands air or sea not super but instructor
inside the constructor we have to call super.
We also have to do that same kind of little initialization line because we are extending a built in
class.
Will do object set prototype of this and database connection air dot prototype and then in this case
I'm going to hard code in the reason that we are throwing this error.
So I will put in a fixed reason property right here that says something like air connecting to database
now in this case do we actually have to extend air or something like database connection air over really
trying to communicate in this case is a fixed string so perhaps it doesn't make a lot of sense to make
a base class.
I just wanted to give you kind of a counterpoint.
I want to give you a second subclass to create beyond just request validation error.
So we're going to be mostly just focusing on request validation error for right now.
Again I just want to give you some other area that we could possibly create that might make sense in
an application like this.
OK so now you put these two air subclasses together we're going to import them into the request handler
and then anytime something goes wrong inside there we're going to throw either request validation error
or database connection error so I have to go back over to my sign up root handler
and then at the top I'm going to import those two custom subclasses.
We just put together so request validation error
and database and auctioneer
now we're going to make sure that then rather than throwing a very generic error we will instead throw
it in the instance of request validation or database connection down inside of my implementation I'm
going to find where we check to see if there were any errors during validation going to delete everything
inside their and replace it with row new request validation error and I'll pass in our list of errors
so errors dot array like so I'll then do something very similar for the other error right here rather
than throwing a very generic error that doesn't really tell us a lot about what is going on.
Instead throw a new database connection air
OK so that is step one we have now subclass error created these two very custom errors we are throwing
them out of our request handler they're going to eventually show up inside of our area handling middleware
and so now the last thing we have to do is add in some code to inspect the incoming error and check
to see if it is an instance of request validation error or an instance of database validation error
and if it is we can build up our response and send back to the user appropriately so quick pause right
here we're gonna build this last up out in just a moment and all this stuff is going to start to come
together very very quickly.