express-async-errors

express-async-errors is a tiny compatibility patch for Express 4 that lets async route handlers and middleware propagate rejected promises straight to Express’s error-handling middleware. Instead of wrapping every async handler in a try/catch and manually calling next(err), you require the module once at startup and any thrown error or rejected promise inside a route, middleware, or app.param() callback is automatically forwarded to the next error handler.

Under the hood it works by redefining the handle property on Express’s internal Router Layer prototype, wrapping every handler function so that if it returns a promise, a .catch() is attached that calls next(err) with whatever error occurred. It also patches Router.param so async param handlers get the same treatment. The patch is applied once, in place, without touching any other part of Express, so the rest of the application uses express normally.

What You Get

• Automatic promise rejection handling for async route handlers
• Automatic error handling for async middleware, including error-handling middleware itself
• Support for async app.param() callbacks
• A single require() call with no configuration or API surface to learn

Common Use Cases

• Simplifying async database queries in route handlers without try/catch boilerplate
• Centralizing error handling in one Express error-handling middleware
• Retrofitting an existing Express 4 app to support async/await safely
• Building REST APIs where every handler is an async function

Under The Hood

Architecture The entire patch lives in a single file, index.js, with no internal layering: it redefines the handle property on Express’s internal Layer.prototype as a getter/setter, and wraps Router.prototype.constructor.param in a patchRouterParam() call. Every handler function assigned to a Layer’s handle property is transparently replaced with a wrapped version that captures the returned value, attaches a .catch(err => next(err)) if it looks like a promise, and copies the original function’s properties and length so Express’s internal arity checks (which decide whether a handler is a 4-arg error handler) still work. There is no exported API, no internal state beyond the one-time monkey-patch, and nothing would break by removing an abstraction because there isn’t one to begin with — the whole surface area is this one wrap function.

Tech Stack Plain CommonJS JavaScript with a peer dependency on express ^4.16.2 and no runtime dependencies of its own. Development tooling is ESLint with the airbnb-base config, Mocha for the test runner, supertest for HTTP assertions against a live Express app, and nyc for coverage reporting. There is no build step or transpilation — the published package is the raw source file.

Code Quality test.js covers the main paths with mocha + supertest: errors thrown in a route handler, errors thrown in regular async middleware, errors thrown inside an async error-handling middleware, errors thrown in an async app.param() callback, and a regression test asserting the router’s internal stack (including custom metadata attached by tools like Swagger generators) is preserved after patching. Given the library’s narrow scope this is reasonably thorough coverage relative to size, though there are no TypeScript types and error handling is implicit (a promise-shaped return value is duck-typed via ret.catch) rather than explicitly validated.

API Design There is effectively zero API surface — you require('express-async-errors') once before defining routes and everything else works exactly as vanilla Express. That absence of ceremony is the library’s main developer-experience strength: no wrapper functions to apply per-route, no need to change how handlers are written. The technique itself (monkey-patching Layer#handle) is borrowed from an earlier generator-based library (express-yields) rather than being a novel approach, and the same outcome is achievable natively in Express 5, which added built-in async error handling.