Error Handling Middleware Patterns — Node.js & Express Backend

Error handling is the part of an Express application that most developers implement last and test least, which is why it is also the part most likely to fail in production. A well-designed error handling system does several things simultaneously: it prevents the application from crashing on unhandled errors, it sends meaningful error responses to clients without leaking sensitive internal details, it logs errors with enough context to diagnose the root cause, and it distinguishes between operational errors that are expected and recoverable and programmer errors that indicate bugs requiring immediate attention. Express provides the four-argument error handler as its primary error-handling primitive, but building a robust system around it requires understanding several patterns that go beyond simply catching errors and sending a 500 response.

Analogy🏏Cricket

🏏 Think of it like cricket: In a Test match, there are multiple types of scheduled breaks and interruptions, each with different priority levels and timing rules. The lunch break (setTimeout) is scheduled for a specific time but can be delayed if a wicket falls just before — it fires at the next available opportunity after its scheduled time, not at the exact scheduled time. The drinks break (setImmediate) is taken at the end of the current over, as soon as the ongoing delivery sequence finishes. The umpire's over-rate check (process.nextTick) happens immediately after each delivery, before the next batsman faces — it cannot be deferred. The DRS review resolution (Promise microtask) happens between deliveries, after the umpire check but before any scheduled breaks. Just as the match referee would be furious if an umpire kept conducting over-rate checks after every single ball indefinitely (starving nextTick), the event loop is unable to proceed if process.nextTick callbacks keep registering new nextTick callbacks recursively. The insight is that each timer primitive is not just a delay mechanism — it is a specific position in a formal protocol, and misusing it violates that protocol's invariants.