A practical checklist for error handling

This is cheap to get right at the start and expensive to retrofit. Run through this the next time error handling comes up.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. If two people in the business would answer this differently, that gap is the actual problem.

The checklist

• Swallowing errors silently is how bugs survive for months
• Fail loudly in development, gracefully in production
• Log enough context to reproduce without guessing
• Someone is named as the owner
• There is a date to review it again

The reason this keeps coming up

Swallowing errors silently is how bugs survive for months. Where this goes wrong is almost never a lack of knowledge. It is the sort of thing that looks like polish right up until it costs you an enquiry.

How to tell if yours is fine

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
• Swallowing errors silently is how bugs survive for months — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.