Error Handling in Express

[00:00:00]
>> Scott Moss: error handling, this is pretty straightforward because it's mostly middleware, but it's a little special, so we've already been kind of handling our errors. Somewhat, responsibly doing our try catches and things like that, but if you want to format or report your errors to like third party things, log them and other services, it's best to probably do that in one centralized place. So very similar to how we had like a centralized place to authenticate. Our routes we can do the same thing with error handling using middleware.

[00:00:19]
Our routes we can do the same thing with error handling using middleware. So error handling, just like middleware can be used in different places in the code level, on the route level, on the router level, on the app level, we're gonna talk about the middleware version which can be applied to pretty much all that except for the code level. The code level is what the try catch is for So how does error handle middleware work and Express? It's literally the exact same thing as regular middleware, except it's it takes 4 arguments, and its first argument is always an error.

[00:00:33]
It's literally the exact same thing as regular middleware, except it's it takes 4 arguments, and its first argument is always an error. Express will look at the signature of the function to determine. If this is an error handle middleware or not. I think that's called what the What's the word called arity of a function maybe something like that where you can just how many arguments a function takes so if you register a middleware that takes 4 arguments expressive like oh that's an Error Handler.

[00:00:52]
I think that's called what the What's the word called arity of a function maybe something like that where you can just how many arguments a function takes so if you register a middleware that takes 4 arguments expressive like oh that's an Error Handler. I'm not sure if I would do that today, but back then it was OK to do stuff like that That's just like it's like one of those things that feels magical, but why are you doing that? Just let me register an Error Handler that's explicitly an Error Handler, but I digress. So the other thing about it is that to trigger the Error Handler.

[00:01:12]
So the other thing about it is that to trigger the Error Handler. Throwing an error won't do that. Throwing an error in your middleware or your controller will just kill your server. If you want to trigger the Error Handler.

[00:01:31]
If you want to trigger the Error Handler. You have to call Next. And pass it in error. So technically you can call Next inside your Controllers, although I said you should never do that, but technically you can and have your error handle it.

[00:01:45]
So technically you can call Next inside your Controllers, although I said you should never do that, but technically you can and have your error handle it. You definitely will call Next inside of your middleware, otherwise you'll just hang if you're not returning So it's mostly for like for that, but yeah, you could call Next inside of your Controllers. The problem with that in my opinion. Is that you're assuming that these Controllers are being registered to some route somewhere that underneath those routes there's an Error Handler.

[00:01:59]
Is that you're assuming that these Controllers are being registered to some route somewhere that underneath those routes there's an Error Handler. But maybe that's fine and you handle that, but that's what the assumption is, because if you call Next with an error inside of a controller. There it's not gonna run another route that's a terminal route like once you're inside of a controller it's resolved, it's not gonna go to somewhere else unless there's an Error Handler, so you have to know that the Error Handler is there. It's almost like writing a component.

[00:02:15]
It's almost like writing a component. And React. And you put some assumptions in that component because you know what it's parent component's gonna look like and you know how it's gonna be rendered so you did some stuff in that component whether it's like UI wise style wise or logic wise like oh I just know that like the parent has to look like this so that makes your component not that flexible anymore you can't really move it around and put it in different places like you know like some libraries will have like. They'll have like a table component and then that table component will have a table.

[00:02:30]
They'll have like a table component and then that table component will have a table. Row component and then that. Table might have like a table. Column component and those row and column components can't work unless they're inside the table component so those components are assuming that they're gonna be in a table component so they're not that flexible anymore.

[00:02:43]
Column component and those row and column components can't work unless they're inside the table component so those components are assuming that they're gonna be in a table component so they're not that flexible anymore. That's the same thing here if you put like a Next inside of. A controller that controller is not that flexible anymore and maybe it didn't need to be in the first place, but that's what you're giving up. The error will skip any middleware, so like once you call Next with an error, everything after that gets skipped, no middleware, nothing else is gonna run it's gonna go straight to your the nearest Error Handler.

[00:03:02]
The error will skip any middleware, so like once you call Next with an error, everything after that gets skipped, no middleware, nothing else is gonna run it's gonna go straight to your the nearest Error Handler. Right, and error handlers can also call Next and Go to the Next Error Handler If you have multiple error handlers registered at different places.