Handling async errors in Express middleware

WHAT THIS TESTS This checks whether you know that Express middleware error handling is built around the next callback and that async rejections need explicit forwarding in the classic versions.

A GOOD ANSWER COVERS Middleware receives req, res, and next. For asynchronous work like a database fetch, you mark the function async and await the operation inside a try block. On success you attach the result and call next to continue. On failure, the catch block calls next with the error, which routes control to Express's error-handling middleware, the special four-argument handler with err, req, res, and next. The critical point in Express 4 is that throwing or rejecting inside an async function is not caught by Express automatically, so an unhandled rejection leaves the request hanging and never sends a response. To avoid repeating try/catch everywhere, teams use a small higher-order wrapper that takes an async handler, runs it, and pipes any rejection into next. Express 5 improves this by forwarding rejected Promises to the error handler automatically.

COMMON WRONG ANSWERS Assuming Express 4 automatically catches async throws, calling next without the error so it falls through to normal middleware, sending two responses, or swallowing the error silently in catch without forwarding it.

LIKELY FOLLOW-UPS What distinguishes error-handling middleware by its four parameters, how the async wrapper works, behavior changes in Express 5, and why you must not call next after already sending a response.

ONE CONCRETE EXAMPLE A middleware loads the current user: it awaits userService.findById inside try, sets req.user, and calls next on success. If the database query rejects, the catch calls next with the error, and a central error handler responds with an appropriate status and JSON body. Without that try/catch in Express 4, the rejection would be unhandled, the central handler would never run, and the client would wait indefinitely until a timeout.