Express error-handling patterns we flag most often
Express makes it easy to ship routes quickly and equally easy to mishandle failures. These patterns appear in roughly half of the APIs we review.
Async routes without a wrapper
Throwing inside an async handler bypasses `next(err)` unless you wrap handlers or use Express 5’s native async support consistently. Mixed styles in one router file cause unhandled rejections.
Four-argument middleware placed too early
Error handlers must come after routes. Teams sometimes register them before new routers during fast feature work, leaving gaps.
Mapping all errors to HTTP 500
Validation and auth failures should surface stable 4xx codes with safe bodies. Logging the internal cause while returning a generic message is fine; returning stack traces is not.
Swallowing errors in service layers
Catch blocks that return `null` without logging force controllers to guess failure modes. Prefer typed errors bubbled to a single serializer.
If you want these issues catalogued for your codebase, consider a structured review.