Express: Error Handling design question and best practices

[officer-rosmarino]

Hi, I am sorry if this post doesn't follow the rules, but I'm having a hard time finding answers in other places.
I have wandered around the web in order to find a solution to this dilemma.

I am wondering what are the best practices when dealing with errors in Express.js. In particular, when a particular route is executed and error occurs that needs to be reported to the client, should I deal with the error there on the spot, or always pass it to the error middleware?

For instance, if I pass the error to a middleware, I would have something like this:

app.post('/someapi', (req, res, next) => {
    if(req.params.id == undefined) {
       let err = new Error('ID is not defined');
       return next(err);
    }
    // do something otherwise
});

app.use((err, req, res, next)=>{
   res.status(err.status || 500).send(err);
});

when, instead, if I would deal with the error on the spot, I would do something like this:

app.post('/someapi', (req, res, next) => {
    if(req.params.id == undefined) {
       let err = new Error('ID is not defined');
       return res.status(ErrorCode).send(err.message);
    }
    // do something otherwise
});

[NickNaso]

Hi @honestserpent,
the errorhandler middleware is a particular middleware and you activate it by calling next(err). The reported error handler is very simple, but you can customize and improve it and create a response based on your the error code generated by the system. In this way you can avoid to write the code to handle the error every time on single route. You can see at this link https://github.com/i0natan/nodebestpractices/blob/master/sections/errorhandling/centralizedhandling.md on how to create a centralized error handler.

[wesleytodd]

Hey @honestserpent, most of the time it is better to ask on Stack Overflow. But if we can help here without creating too much email spam to the ~2k people who watch this repo, then great!

As to your question, either of your approaches are good, but they have pros and cons. Personally I think having errors handled at the "error site" is beneficial if you have a large team which will be working on the app, or you see the app living for a long time and needing to support growth. It enables each developer to decide how their addition will work without having to know about all the other decisions team members have made.

Alternatively, the central error handling approach is good for when you want the developers working on a project to all agree on a single way to handle errors. It often means you have to abstract your error handling a little to handle all error conditions of your app, and as we all know, a leaky abstraction is worse than no abstraction. So Just be aware of the trade off.

Now how I personally set things up. I use a combination of the two approaches. I like to define central error handling for generic common uses cases for my app (404, 500, 409, sometimes 403/401 depending on the app). Then for more unique error conditions, like failing to meet specific input validation I handle those at "error site". This means that if a developer accidentally forgets to handle a common error the app will take care of it for them, but they still have the ability and flexibility to handle the one-off errors or application logic specific cases in a debuggable and understandable way.

Hope that helps!

[officer-rosmarino]

@NickNaso yes well, the reported error handler was left intentionally simple just to explain the fact that there is an error middleware. Thank you for your link, According to that so you shouldn't handle errors in a middleware, but in a central function place. Nice, looks like a nice approach.

Do you maybe have a more complete and real-world example of the one in the link you provided?

@wesleytodd Yes, I'll post on StackOverflow too :)
Thank you very much for your suggestions

[wesleytodd]

Closing as resolved.