All 15 Error Handling questions
More in Error Handling
What is the difference between operational errors and programmer errors in Node.js, and why does this distinction matter? What is the difference between throwing an error synchronously and calling a callback with an error as its first argument in Node.js? How would you create and use custom Error subclasses in a Node.js application to represent different categories of application-specific errors? How do you correctly propagate and handle errors from a Node.js stream, given that stream errors aren't caught by a surrounding try/catch? 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 a centralized error-handling middleware pattern in Express, and what advantages does it provide over handling errors in each individual route? 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?
Advertisement
Node.js › Error Handling

Why doesn't Express automatically catch errors thrown inside an async route handler in versions prior to Express 5, and how do you work around this?

Intermediate

Answer

In Express 4 and earlier, if an async function passed as a route handler throws (or its returned promise rejects), Express's underlying error-handling doesn't automatically catch it the way it does for synchronous throws, because Express predates widespread async/await and doesn't await the handler's returned promise -- the common workaround wraps every async handler in a helper that catches rejections and forwards them to next(), or uses a library like express-async-errors that patches this behavior globally.
// Manual wrapper approach
const asyncHandler = (fn) => (req, res, next) => Promise.resolve(fn(req, res, next)).catch(next);

app.get('/users/:id', asyncHandler(async (req, res) => {
  const user = await getUserOrThrow(req.params.id); // if this throws, asyncHandler catches and forwards it
  res.json(user);
}));
Real-world example A team on Express 4 noticed that an unhandled rejection inside an async route handler was crashing their entire server rather than being caught by their error middleware, until they wrapped every async route with a small asyncHandler utility that properly forwards rejected promises to Express's next() function.

Common follow-ups: How does Express 5 change this default behavior regarding async route handlers?;What's the risk of forgetting to wrap even a single async route handler in a codebase relying on this manual pattern?

Express & Middleware;Async Patterns
All 15 Error Handling questions