API Design in Node.js, v4

Creating Error Handlers

Scott Moss

Scott Moss

Superfilter AI
API Design in Node.js, v4

Check out a free preview of the full API Design in Node.js, v4 course

The "Creating Error Handlers" Lesson is part of the full, API Design in Node.js, v4 course featured in this preview video. Here's what you'd learn in this lesson:

Scott demonstrates how errors cause a Node server to shut down. Express has built-in error handling, however, the default behavior is to output the error message and stack trace. Creating error-handling middleware allows the application to respond differently depending on the error thrown.


Transcript from the "Creating Error Handlers" Lesson

>> All right, let's talk about error handling. I'm gonna push this up, and we'll talk about error handling, which we desperately need as you saw. [LAUGH] So if we go over to the site, we can talk about errors. So how do errors work in Express, or even node?

Anyone knows what happens if you throw an error at node? Ever tried to do that before, check this out, so if I go, was gonna go a little JavaScript file right click, it's gonna call it error.Js. I'm gonna go in here, I wanna throw there. If I run this file, what you think is gonna happen?

>> Pop up?
>> Yeah, it's just got a break. I mean, even the linter knows what's gonna happen, it literally dimmed out this code, it's like this code is never gonna run. What are you doing? This is gonna break everything, right? So if I go to terminal and I type in node and I run that file, it literally just breaks immediately.

Okay, your server, because it runs a node is no different. It too will do that. It will just break whenever there's an error, but Express knew that, so this kind of saved us a little bit. What Express does, Is that any error that is thrown inside of a handler or a middleware, basically inside the framework.

If it's a synchronous error, we'll talk about asynchronous errors in a minute. If it's a synchronous error, Express will catch that error for you, to prevent your server from crashing. And that's why on some errors we'll get back that HTML page, that's Express setting that back cuz it caught the error for us.

And I was like, you didn't do a try catch. Don't worry, I got you, I did it for you, and it sent back that HTML document. And we could test that. So if I go to, I'm gonna delete this file, we don't need this file. I'm just gonna make, I don't know, a quick little route right quick.

So I'm gonna go to server. Actually, let's do it right here on the get to slash. I'm just gonna throw an error, so I'm just gonna say, throw new error, hello. So I'm gonna throw that error, Start my server, and I'm gonna make a request to that. All right, so you can see right here, I get this HTML back.

This is Express. Express is like, if I would have put this on a screen, it would show the stack trace and everything on the screen in the browser, right? This is just raw HTML. I can actually go to the browser and show you. All right, so you get this back.

This is what Express is getting back, but our server's still on, it didn't crash, still running. Express caught the error, it was like, it's a 500 error because you didn't catch it, that means your server's messed up. So it's a 500, and then don't worry, I'll tell you what it was.

That's cool, but you probably don't wanna be showing this to your users, okay. And second of all, it might not have been a server error. It could have been a user error, you just didn't catch it. And it could have been anything. It might not have been your fault, but you didn't handle it.

So Express handled it. We probably won't override this, and we will, and we can. And the way that you do that, is with their own error handler. So, basically, you can create an error handler and Express the same way you create a middleware, or a database handler, or route handler.

The only difference is that it has basically four arguments. Where's the first argument is the error that was thrown, and everything else is what you already know. That's it. Other than that, it can do the same thing any other handler can do, the same thing any other middleware can do.

The only difference is where you put it, because an error handler can't catch an error until the error was thrown. So that means the error handler has to come after all the routes. If you made an error handler before route, like you told app.use, hey, here's my error handler.

And then after that you made all your routes, that handler would never catch the errors because it was registered before your routes were. So Express would never bubble your errors up to that error handler. So basically, you need to make sure you register your error handlers at the bottom of all your routes, so that they can be caught by your error handler.

And that looks like this. So if I were to go into the code and I were to make an error handler for the thing that we just did, so you can see I have this error being thrown. I'm gonna go down here, underneath everything, and I'm gonna say app.use this error handler, req, res, next.

And I can log this error. I can say, log this error and I'm just gonna say res.json, not jon, I don't know who jon is, that jon, message, oops, there was an error. I could do that. I'm gonna log it so I can see it, but then I'm gonna send this back to the user, something a little different.

So now if I say, run that, And then go back here and refresh, look, I get that custom message. And in the terminal I still logged it. So my error handler took over from what Express already had. And you could do whatever you want in here. You could do asynchronous things in here, too.

So this is a perfect place to add instrumentation, error logging, error reporting, all that stuff, it's perfect.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now