How do you handle uncaught exceptions?

Uncaught exceptions are errors that occur during the execution of a Node.js application and are not caught by any `try...catch` block. When such an exception occurs, the Node.js process by default will terminate immediately. Properly handling these exceptions is crucial for application stability and reliability.

Understanding Uncaught Exceptions

An uncaught exception typically indicates a bug in the application logic that wasn't anticipated. If left unhandled, it can lead to abrupt server crashes, loss of ongoing requests, and an inconsistent application state. While try...catch blocks are used for synchronous error handling, they cannot catch errors thrown asynchronously, for instance, from event emitters or callbacks.

The `process.on('uncaughtException')` Event

Node.js provides a global uncaughtException event on the process object. This event is emitted when an exception bubbles all the way up to the event loop without being caught. Listening to this event allows you to perform cleanup operations before the process exits gracefully.

process.on('uncaughtException', (err) => {
  console.error('Uncaught Exception thrown:', err);

  // Perform any necessary cleanup (e.g., close database connections, log error)
  // It's crucial to terminate the process after an uncaught exception
  // as the application state might be corrupted.
  // This allows external process managers (like PM2 or Kubernetes) to restart the app.

  process.exit(1); // Exit with a failure code
});

// Example of an uncaught exception
setTimeout(() => {
  throw new Error('This is an uncaught async error!');
}, 1000);

// Example of a synchronous uncaught exception (though less common in real apps)
// If not wrapped in try-catch, this would also be caught by uncaughtException
// const invalidOperation = undefined.foo();

Best Practices for Handling Uncaught Exceptions

• Log the Error: Always log the full stack trace and relevant context of the error to a persistent store (e.g., file, logging service) for debugging.
• Perform Graceful Shutdown: Before exiting, attempt to close any open resources like database connections, file handles, or gracefully shut down HTTP servers to prevent hanging connections or data corruption.
• Terminate the Process: After an uncaughtException, the application state is often unpredictable. The safest approach is to log the error, perform cleanup, and then terminate the process (e.g., process.exit(1)).
• Utilize Process Managers: Rely on external process managers (like PM2, forever, systemd, or orchestration platforms like Kubernetes) to automatically restart your application after it exits due to an uncaught exception. This ensures high availability.
• Avoid Continuing Operation: Do not attempt to recover and continue normal operation after an uncaughtException. The integrity of the application's state cannot be guaranteed.

Handling Unhandled Promise Rejections (`unhandledRejection`)

While not strictly 'exceptions', unhandled promise rejections are a common source of runtime errors in Node.js. If a Promise is rejected and no .catch() handler is attached to it, Node.js emits the unhandledRejection event. This event is similar to uncaughtException in that it indicates a potentially unhandled error.

process.on('unhandledRejection', (reason, promise) => {
  console.error('Unhandled Rejection at:', promise, 'reason:', reason);
  // Application specific logging, cleanup, and exit logic
  // Typically, an unhandled rejection should also lead to process termination
  // as it signifies a serious error that was not anticipated.
  process.exit(1);
});

// Example of an unhandled promise rejection
new Promise((resolve, reject) => {
  reject(new Error('This is an unhandled promise rejection!'));
});

What NOT to do

• Do Not Restart Application Logic: Do not try to re-initialize your application inside the uncaughtException handler. This can lead to resource leaks and further instability.
• Do Not Ignore Errors: Never just log and continue. Both uncaughtException and unhandledRejection are critical signals that your application is in an unstable state.
• Avoid domain Module: The domain module was previously used for error handling but is now deprecated and generally discouraged for new code due to its complexity and performance implications.