Introduction

Async route handlers in Express are convenient, but error handling depends on how the error reaches Express. If an asynchronous function throws or rejects and Express never receives that error, the request can hang or the process can log an unhandled rejection instead of returning a proper HTTP response.

The right pattern depends on your Express version. In Express 5, rejected async handlers are forwarded automatically. In Express 4, you usually need to pass errors to next yourself or wrap the handler.

Express 5: Async Errors Are Forwarded Automatically

In Express 5, an async route handler that throws or rejects is treated as an error and forwarded to the error middleware.

1const express = require("express");
2const app = express();
3
4app.get("/users/:id", async (req, res) => {
5  const user = await getUserById(req.params.id);
6  res.json(user);
7});
8
9app.use((err, req, res, next) => {
10  console.error(err);
11  res.status(500).json({ error: err.message });
12});

If getUserById throws, Express 5 will call the error middleware automatically.

Express 4: You Must Forward Async Errors Explicitly

In Express 4, an async handler does not automatically hand rejected promises to Express. The usual pattern is a try and catch block.

1const express = require("express");
2const app = express();
3
4app.get("/users/:id", async (req, res, next) => {
5  try {
6    const user = await getUserById(req.params.id);
7    res.json(user);
8  } catch (err) {
9    next(err);
10  }
11});
12
13app.use((err, req, res, next) => {
14  console.error(err);
15  res.status(500).json({ error: err.message });
16});

The key step is next(err). That is what transfers control to Express error-handling middleware.

A Reusable Async Wrapper

To avoid repeating try and catch in every route, many Express 4 codebases use a small wrapper.

1const asyncHandler = (fn) => (req, res, next) => {
2  Promise.resolve(fn(req, res, next)).catch(next);
3};
4
5app.get(
6  "/users/:id",
7  asyncHandler(async (req, res) => {
8    const user = await getUserById(req.params.id);
9    res.json(user);
10  })
11);

This is a clean pattern because it keeps route handlers focused on business logic while ensuring promise rejections are forwarded correctly.

Error Middleware Must Come Last

Express only uses error middleware if it is registered after your routes and other middleware.

1app.use((err, req, res, next) => {
2  res.status(err.status || 500).json({
3    message: err.message || "Internal Server Error",
4  });
5});

Also remember that error middleware has four arguments: (err, req, res, next). Without the err parameter, Express does not treat it as an error handler.

What About Errors in Timers or Callbacks?

Errors thrown inside plain callbacks such as setTimeout are different from rejected promises. Express cannot catch them automatically unless you route them back through next.

1app.get("/timer", (req, res, next) => {
2  setTimeout(() => {
3    try {
4      throw new Error("Timer failed");
5    } catch (err) {
6      next(err);
7    }
8  }, 100);
9});

This matters because not all asynchronous code in Node is promise-based.

Returning After next(err)

A subtle bug appears when code calls next(err) and then keeps going. That can lead to double responses.

1app.get("/demo", async (req, res, next) => {
2  try {
3    throw new Error("Broken");
4  } catch (err) {
5    return next(err);
6  }
7});

Using return next(err) is a simple way to stop the handler after the error is forwarded.

Common Pitfalls

One common mistake is assuming async and await automatically make Express catch everything. That is only true for rejected route-handler promises in Express 5, not for every asynchronous callback pattern.

Another issue is forgetting to register error middleware last. If it is placed before the routes, it will not handle the route errors the way you expect.

It is also easy to call res.send(...) and then later call next(err) after headers have already been sent. At that point, error handling becomes more complicated and the connection may already be partially committed.

Finally, do not swallow errors in a catch block without responding or calling next. That creates hanging requests.

Summary

• In Express 5, rejected async route handlers are forwarded to error middleware automatically.
• In Express 4, use try and catch with next(err) or wrap handlers with a reusable async helper.
• Error middleware must appear after routes and must use the four-argument signature.
• Promise rejection handling and plain callback error handling are not the same thing.
• A good async error pattern prevents hung requests and keeps route code readable.