All 15 Error Handling questions
More in Error Handling
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? 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? 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

How would you implement a global 'not found' (404) handler in Express for any route that doesn't match a defined endpoint?

Intermediate

Answer

A catch-all middleware placed after all defined routes (but before the error-handling middleware) matches any request that hasn't already been handled by an earlier route, letting the application return a consistent, well-formatted 404 response rather than Express's default plain-text 'Cannot GET /some/path' message.
// After all your defined routes
app.use((req, res) => {
  res.status(404).json({ error: 'Not Found', path: req.originalUrl });
});

// Error-handling middleware still goes after this
app.use((err, req, res, next) => { /* ... */ });
Real-world example An API that previously returned Express's default plain-text 404 page adds a catch-all JSON 404 handler, ensuring every unmatched route (a typo'd endpoint, a deprecated API version) returns a consistent, machine-parseable JSON error response matching the rest of the API's error format.

Common follow-ups: Why must this catch-all handler be placed after every other route definition to work correctly?;How would you distinguish a genuinely undefined route from a route that exists but the specific resource ID wasn't found?

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