Error Handling with Node.js and Express

Probably a topic that has been written on quite a bit but as with some blog posts, doing it one more time is hopefully another piece of community documentation as well as potentially helpful to someone struggling with a task.

Express is probably the web framework that most people hear/learn about first and with my limited Node experience the first one I came across.  The following paragraphs won’t be about competitors to it or really more beyond what the title describes, but if you are interested, check out (there are several others)

This week while looking at a bug in our platform, I realized quickly that the application was not the problem, yet the underlying API which is written in Node and utilizing Express.  I kept seeing in the logs “Can’t set headers after they are sent to the client”.  When looking at the route, the first thing I noticed was that when an error was occurring the code was just using 500 as a catch all and then calling

Beyond the generic exception, in the app.js there was an attempt at an error handler setup which was also sending headers back to the requestor.  So to clean this code up and put a better status on response I changed to this

So I cleaned up the code inside of the route which both returns a response correctly and doesn’t double send headers as that res.status(200).json({}) won’t be called unless there truly are no errors in the processing that the API is doing. Now popping on over to app.js which handles app setup and route configuration, I added the following at the bottom of the file.  Important Note: Adding a wildcard route must be at the bottom as it is essentially a “fallout” and it’ll match anything.

Few things about the above.

  1. Note that before anything I have that wildcard route and I’m treating those requests as Not Found and returning 404 as the HTTP status.
  2. Development based route for error handling.  In the payload in the response, I’m setting error: err which will show the actual descriptive error that I probably care about only when in development. Notice no next() as I want to end the pipeline right there
  3. The production handler that only returns the HTTP status and the error message I want.  Such as “Invalid Request”, “Bad Request, check your parameters” or whatever I want to return to the caller.

Like I mentioned in my last post, I’ll be sharing things I’ve learned, am learning or just general fodder along the way.  I hope this is helpful to someone and if not applicable to what you are working on, perhaps just something new that you can file away!


About the author

Ben Pyle is a software developer who enjoys solving problems and delighting customers with right quality software. He's a husband, father to 2 boys and avid golfer. In his free time he enjoys reading, playing lots of golf and hanging out with his family doing whatever they are into.

Leave a Reply

Your email address will not be published. Required fields are marked *