Global Error Handling in Node.js & Express

Build resilient and production-ready applications by mastering a centralized strategy for handling any error your server encounters.

Server Online

Welcome! Let's learn to make our Node.js server robust and prevent it from crashing.

/* Initializing a stable server... */

The Global Error-Handling Middleware

The cornerstone of Express error handling is a special type of middleware. Unlike regular middleware, it has four parameters: (err, req, res, next). This signature allows Express to recognize it as an error handler. It must be defined last, after all other `app.use()` and route calls.

Handling Synchronous & Asynchronous Errors

For asynchronous code (like database calls), Express cannot automatically catch errors. You must wrap your async logic in a try...catch block and explicitly pass any caught errors to the global handler using next(error). For synchronous code, simply using `throw new Error()` is enough for Express to catch it.

Process-Level Safety Nets

Some errors happen outside the Express request-response cycle. These are critical. `process.on('unhandledRejection', ...)` catches unhandled promise errors, and `process.on('uncaughtException', ...)` is the final safety net for any other uncaught synchronous error. Handling these is crucial for gracefully shutting down your server instead of crashing abruptly.

The Result: A Resilient Application

A robust strategy involves centralizing error logic, distinguishing between operational errors (e.g., bad user input) and programmer errors (bugs), logging errors effectively, and sending clean, consistent error responses to the client without leaking sensitive details in production.

Practice Zone

Interactive Test 1: Match the Handler

Match the error scenario to the correct handling mechanism.

Arrastra en el orden correspondiente.

Arrastra las opciones:

try { ... } catch (e) { next(e) }

process.on('unhandledRejection', ...)

throw new Error(...)

Completa el código:

Synchronous Error______

Asynchronous Error______

Unhandled Promise______

🔒 Unlock with Premium

Interactive Test 2: Complete the Middleware

Complete the signature for a valid Express error-handling middleware.

Rellena los huecos en cada casilla.

app.use(( , , ,  ) => {
  // Error handling logic here...
});

🔒 Unlock with Premium

Practice Example: Code Editor

Create a simple Express route that uses `try...catch` to handle a failed asynchronous operation and passes the error to `next`.

* Write the code below. Correct characters will be shown in green and incorrect ones in red.

app.get('/data', async (req, res, next) => {
  try {
    const data = await fetchSomeDataThatMightFail();
    res.json(data);
  } catch (error) {
    next(error);
  }
});

🔒 Unlock with Premium

Knowledge Check

Where should the main error-handling middleware be placed in your Express application file?

🔒 Unlock with Premium

← Previous Next →

Error Handling in Practice

A solid error handling strategy goes beyond just preventing crashes. It involves creating predictable, debuggable, and maintainable code.

1. Creating Custom Error Classes

Instead of throwing generic `Error` objects, create custom classes to handle specific operational errors. This makes your logic cleaner and allows your global handler to react differently to different error types (e.g., a 404 `NotFoundError` vs. a 400 `ValidationError`).

class AppError extends Error {
  constructor(message, statusCode) {
    super(message);
    this.statusCode = statusCode;
    this.status = `${statusCode}`.startsWith('4') ? 'fail' : 'error';
    this.isOperational = true;

    Error.captureStackTrace(this, this.constructor);
  }
}

// Usage: next(new AppError('Resource not found', 404));

2. Don't Leak Details in Production

In your global handler, check the environment. In development, send back the full error stack for easy debugging. In production, send only a generic, user-friendly message to avoid exposing implementation details or security vulnerabilities.

if (process.env.NODE_ENV === 'development') {
  res.status(err.statusCode).json({
    status: err.status,
    error: err,
    message: err.message,
    stack: err.stack
  });
} else { // Production
  res.status(500).json({
    status: 'error',
    message: 'Something went very wrong!'
  });
}

3. Abstracting Async Logic with a Wrapper

Writing `try...catch` in every async controller can be repetitive. Create a higher-order function that wraps your async functions, catches any errors, and automatically calls `next(error)`.

const catchAsync = fn => {
  return (req, res, next) => {
    fn(req, res, next).catch(next);
  };
};

// Usage: router.get('/users', catchAsync(getAllUsers));

Practical Takeaway: Robust error handling is not an afterthought; it is a foundational piece of architecture that defines the stability and professionalism of your backend service.

Error Handling Glossary

Error-Handling Middleware: A special Express middleware function with the signature `(err, req, res, next)` that executes when an error is passed to `next()` or thrown synchronously in a route.
Stack Trace: A report of the function calls on the execution stack at the time an error was thrown. It's essential for debugging to see where the error originated.
Operational vs. Programmer Error: Operational errors are expected problems (e.g., invalid input, DB connection fail), which should be handled gracefully. Programmer errors are bugs in the code (e.g., reading property of `undefined`), which should crash and be fixed.
`unhandledRejection`: A Node.js process-level event that is emitted whenever a Promise is rejected and there is no `.catch()` handler to deal with the rejection. A critical safety net.
`uncaughtException`: A process-level event for synchronous errors that were not caught anywhere in a `try...catch` block. This is the last resort before the process terminates.