A short guide to error handling

This is cheap to get right at the start and expensive to retrofit. Everything we would tell a client about error handling in the time it takes to drink a coffee.

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.

What it costs to ignore

Swallowing errors silently is how bugs survive for months. That sounds obvious written down. It is still the thing most often skipped. It is the sort of thing that looks like polish right up until it costs you an enquiry.

What good looks like

Fail loudly in development, gracefully in production. It is worth being explicit about, because assumptions differ quietly. It rarely shows up as a line item, which is exactly why it slips.

Warning signs

Log enough context to reproduce without guessing. This is the sort of thing that compounds, quietly, in both directions. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

In practice

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
• Log enough context to reproduce without guessing — and you know whether that is true here
• There is a way to tell whether the last change to this helped

The point is not perfection, it is knowing which of these you have consciously chosen to skip.