All 15 Error Handling questions
More in Error Handling
What is the try/catch/finally pattern's 'finally' block used for, and how does it behave with async/await? What is the risk of exposing a raw error's stack trace in an API response, and how do you prevent it while still logging full details server-side? What is the difference between a validation error and a business-logic error, and how might a Node.js application handle each differently? How would you implement a global 'not found' (404) handler in Express for any route that doesn't match a defined endpoint? What is the difference between a 4xx and 5xx HTTP status code from an error-handling perspective, and how should a Node.js API decide which to return? What is error wrapping (or error chaining), and how does the Error class's 'cause' property support it in modern Node.js? How would you implement a global error boundary for an entire Node.js application to ensure no error type goes completely unhandled? How would you implement error handling for a GraphQL API in Node.js, given GraphQL's different error-response format compared to REST? How would you implement automatic error reporting to a service like Sentry in a Node.js application, and what data should be scrubbed before sending?
Advertisement
Node.js › Error Handling

What is a centralized error-handling middleware pattern in Express, and what advantages does it provide over handling errors in each individual route?

Advanced

Answer

Express supports a special error-handling middleware signature (with four parameters: err, req, res, next) placed at the end of the middleware chain -- any error passed to next(err) anywhere in the request pipeline (or thrown inside an async route wrapped appropriately) is routed to this single centralized handler, letting error formatting, logging, and status-code mapping happen consistently in one place rather than duplicated across every route handler.
app.get('/users/:id', async (req, res, next) => {
  try {
    const user = await getUserOrThrow(req.params.id);
    res.json(user);
  } catch (err) {
    next(err); // delegate to centralized handler
  }
});

app.use((err, req, res, next) => { // must have exactly 4 params
  logger.error(err);
  const statusCode = err.statusCode || 500;
  res.status(statusCode).json({ error: err.isOperational ? err.message : 'Internal server error' });
});
Real-world example An API refactors dozens of route handlers, each with their own duplicated try/catch error-formatting logic, to instead call next(err) and rely on a single centralized error-handling middleware, immediately making error responses consistent across the entire API and simplifying every individual route handler.

Common follow-ups: Why does Express require an error-handling middleware to have exactly four parameters to recognize it as such?;How do you ensure an unhandled error inside an async route handler actually reaches this middleware, given Express doesn't automatically catch async errors by default in older versions?

Express & Middleware;RESTful API Design with Express
All 15 Error Handling questions