Five mistakes teams make with error handling

This is one of those topics that looks small until it costs you something. These are the ones we run into repeatedly when we audit error handling.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Budget a little time for it every quarter and it never becomes a project of its own.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Swallowing errors silently is how bugs survive for months
• Fail loudly in development, gracefully in production
• Never checking whether the fix actually worked

Log enough context to reproduce without guessing. That sounds obvious written down. It is still the thing most often skipped. It rarely shows up as a line item, which is exactly why it slips.

What to do next

The short version

Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about error handling before you move on:

• Someone can say what the current setup is without going to look
• Fail loudly in development, gracefully in production — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.