Three myths about error handling

It comes up on almost every project, usually later than it should. A few things about error handling that get repeated more often than they get checked.

Most development decisions are really maintenance decisions wearing a different hat. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.

“It only matters for big sites”

Swallowing errors silently is how bugs survive for months. Getting it slightly wrong is survivable. Ignoring it entirely is not. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

“We can deal with it after launch”

Sometimes true, usually expensive. This is the sort of thing that compounds, quietly, in both directions.

“Our platform handles it”

Log enough context to reproduce without guessing. In practice this is a scheduling problem more than a technical one. The version that survives contact with a real deadline is the simple one.

In practice

Code gets read far more often than it gets written, and usually by someone with less context than the author had. 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

Pick the one that would hurt most if it failed, and start there.