Error Handler Middleware

[00:00:00]
>> Speaker 1: Let's make one, so what we'll do is we'll make an Error Handler and then we'll register it in our Express server So the simplest way to do that is go to our middleware

[00:00:00]
Create a new one here, we'll call it error handler We'll import our types from Express: requests and response We will export an Error Handler middleware, so what's called Error Handler

[00:00:00]
It's got to take those 4 arguments, so error for now you could just put error class if you wanted to type this out Our request is our request, response response, and then Next is the Next function, there we go

[00:00:00]
Cool, so we got all those First thing is if you want you can just log the entire stack trace of this error if you wanted to

[00:00:00]
That's just something that's helpful I mean this is not something you would do in production I think you would have like a logger that you're logging to, but this is just something I'm doing in development

[00:00:00]
And then there's no wrong answer here Like what we're doing right now at this point is all opinion-based, right This is like how do you handle your errors

[00:00:00]
Do you report to Entry right here Do you have something like a Bugsnag Do you have a logger with something like Pino

[00:00:00]
Are you writing to a file Are you sending off a Slack to alert somebody Like what are you doing here There's no wrong answer

[00:00:00]
You do whatever you want This is saying, "Hey, there was an error in one of the middlewares or the controllers somewhere." And I'm letting you know

[00:00:00]
It also depends on what your errors look like Do you have custom errors that you've created that have different error codes on them that do specific things

[00:00:00]
Inside of here, you do a switch statement on those error codes and depending on that error code, you do something else

[00:00:00]
There's no wrong answer here So everything I have right here is just me showing you what's possible It's not right or wrong; it's really just based on opinions

[00:00:00]
So what I have here is like, "Oh, I'll look at the name of the error Depending on the name of the error, I'll set a different status and a message that I send back to the client." That's a very simple way of doing it

[00:00:00]
You could literally do whatever you want here There's no wrong answer Does that make sense It's mostly the fact that the error was handled, right

[00:00:00]
Because if you don't handle the error, then your server will break What you do with the error is up to you The lesson is handling the error to begin with and how to handle the error

[00:00:00]
So in this case, I'm just setting a status I'll default to error.status if there is one, otherwise I'm just gonna assume we messed up somewhere and I'm gonna do 500

[00:00:00]
And then I'll default to a message If there is a message on the error, I'll use that one, otherwise I'll just say, "Internal server error." Then if error.name equals "validation error", so in this case, something happened on validation like input validation, and I'll say the status equals 400 and the message equals "Validation error"

[00:00:00]
This would free up our validation middleware For instance, they automatically do that themselves They're like, "Oh, I know what the error is

[00:00:00]
I'm just gonna go ahead and respond with the error handling that we're gonna set globally in our app." This middleware no longer has to do this

[00:00:00]
All it has to do is throw an error now It doesn't even have to return; it would say, "Oh snap, there's an error, I'll just call Next with that error object." [The transcript continues in this corrected format, maintaining technical accuracy and cleaning up speech patterns while preserving the speaker's natural voice and technical explanation style.]