Express Error Middleware: Your App's Safety Net

Why it exists

Without a centralized error handler, every route would need its own try/catch block, leading to duplicated code and inconsistent error responses. A single unhandled error could crash the entire Node.js process, taking your service offline. Error-handling middleware provides a single, predictable place to manage all failures.

The mental model

Think of your Express app as an assembly line. Requests move down the line, processed by each middleware station. An error-handling middleware is like a quality control inspector standing at the very end of the line. If any station along the way drops a part (throws an error), the part is immediately pulled off the main line and sent directly to this inspector for final processing, bypassing all subsequent normal stations.

How it works

Express distinguishes error-handling middleware from regular middleware by its function signature. A regular middleware has three parameters: (req, res, next). An error-handling middleware has four: (err, req, res, next). When you call next() with an argument, like next(error), Express skips all remaining regular middleware and jumps to the first middleware in the stack that has the four-parameter signature. Inside this middleware, you can inspect the 'err' object, log it, and send a formatted response to the client. Since Express 5, async route handlers automatically pass promise rejections to the error handler.

When to use it

Use it in every production Express application to create robust services. It is essential for centralizing tasks like: first, logging errors to a file or external service (like Sentry or Datadog); second, hiding implementation details by sending generic error messages to users ('An internal server error occurred'); and third, distinguishing between different types of errors to send appropriate HTTP status codes.

When not to use it

You don't use it for handling expected, non-exceptional failures within a single route's logic, like 'user not found'. While the error handler could catch a 'NotFound' error, it's cleaner to handle that specific case directly in the route handler with res.status(404).send('User not found'). The global error handler is for unexpected or system-level errors, not predictable business logic failures.

One canonical example

An Express application is set up with a route and a final error handler. The route might look like: app.get('/user/:id', async (req, res, next) => { ... }). The error handler must be defined last: app.use((err, req, res, next) => { console.error(err.stack); res.status(500).send('Something broke!'); }). If an async operation inside the route fails, Express 5 automatically calls next(err), skipping to the error handler. This logs the error server-side and sends a generic 500 response to the client, preventing a server crash and leaking stack traces.