All 15 Error Handling questions
More in Error Handling
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? 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 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 error boundary for an entire Node.js application to ensure no error type goes completely unhandled?

Advanced

Answer

A comprehensive strategy layers multiple safety nets: Express's centralized error-handling middleware for errors within the request/response cycle, a process-level 'unhandledRejection' handler for promise rejections that escape all other handling, an 'uncaughtException' handler for synchronous errors that escape everything else (used only for logging and clean shutdown, never to keep running), and structured logging at each layer so every error is captured with enough context to diagnose, regardless of where in the application it originated.
app.use((err, req, res, next) => { logger.error(err); res.status(500).json({ error: 'Internal server error' }); });

process.on('unhandledRejection', (reason) => { logger.error('Unhandled rejection:', reason); process.exit(1); });
process.on('uncaughtException', (err) => { logger.error('Uncaught exception:', err); process.exit(1); });
Real-world example A production Node.js service layers all three of these safety nets, ensuring that regardless of whether an error occurs inside a request handler, an unawaited background promise, or a genuinely unexpected synchronous bug, it's always logged with full context before the process either recovers gracefully or restarts cleanly under a process manager.

Common follow-ups: Why is it important that both unhandledRejection and uncaughtException handlers still call process.exit() rather than just logging and continuing?;How does a process manager like PM2 or Kubernetes ensure the application actually restarts quickly after one of these handlers exits the process?

Advanced Node.js;Deployment & Process Managers (PM2)
All 15 Error Handling questions