The last video we established that we need to make sure that all of our different services respond to
some invalid incoming data with a very similarly structured air response.
So I'm not saying that should always be an array of objects but I'm saying I'm saying that we need to
put some thought into this and make sure that we've got some consistent structure for every kind of
air response we ever expect to send back from any service.
Now I do want to clarify one quick thing.
Right now we are really just talking about the case in which we send over some invalid data inside a
request to one of our given services.
So in other words we're really just talking about this scenario right now.
So in scenario number one we're talking about sending some risk quest over to our art service with an
e-mail of let's say gibberish that is clearly not an email.
So at some point time we're going to run that email through express validator.
And as soon as we do so boom something blows up we throw an error.
We're not really throwing an error per say but we are an error state and we need to stop our request
handler early and send back some kind of a response to whoever made this request.
But again express validator is not the only thing that is going to be producing some kind of error that
we need to send back to the user.
There are many many other scenarios only an infinite number of other scenarios where you are going to
opt to stop a request handler early and send back some kind of response and all these different responses
no matter the source whether it's expressed validator or something else.
We want to make sure that they all have this very identical structure.
So let's start to think about some those other scenarios where something might go wrong and we will
have to send back some kind response that we want to make sure it has this identical structure just
so the react app can pass that error very easily.
So here's another scenario right here.
Let's consider scenario number two.
Maybe we have some incoming requests with an email of test at test dot com.
Well we get through that into express validator and express validator would say Well yeah that's a valid
e-mail.
Everything looks good.
That would then go on to the next step of a request handler where we might check to see if that e-mail
is already in use.
And let's imagine that in this scenario maybe someone has already signed up with an e-mail up test at
test dot com.
So once we do this check right here we once again would probably throw some kind of error or we would
need to throw or send an error back to whoever made this request.
And so we've got the red X right there to indicate something went wrong.
We need to send an error response back so in this case it is not express validator that is producing
some kind of error.
It is this totally unrelated chunk of code.
So again we need to make sure that not only express validator knows how to send back a response of this
structure right here we need to make sure that many other places inside of our code can send back an
identical structure as well.
Melissa even goes on from there.
Let's consider scenario number three.
So maybe with scenario number three we have an e mail test at test dot com.
That is a valid e-mail.
So it will get past express validator maybe in this case we're gonna check to see if the e-mail is already
in use and maybe it's not maybe as an e-mail that we can sign up with and then maybe at that case we
or in this case we just tried to sign up with a new user but for some reason maybe our database connection
is down or something like that.
So once again we have some kind of error that is going to be produced by our application and we need
to somehow capture that error and send back some response to the user.
Once again with a completely identical structure.
So what I'm trying to say here in this series of diagrams is that we have no idea where something is
going to go wrong inside of application.
We might have something go wrong from Express validator and might go wrong during some kind of internal
validation and it might go wrong even at the database access level.
And in all these different scenarios we need to somehow capture these errors as they are occurring and
sent back this identical looking structure no matter what.
Because again we don't want our ReACT application to have to understand how to pass a billion of different
kinds of errors.
We just want to have this one identical structure that it will be used for absolutely everything that
goes wrong inside of application OK.
So now that we've got kind of a scope of this problem and we understand that we really need to have
some robust area handling one more pause right here we're gonna start to investigate how we're going
to implement all this using express.