Error handling: the questions we get asked most

Every audit we run turns up some version of this. The questions about error handling that come up most often on our calls.

Most development decisions are really maintenance decisions wearing a different hat. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Do we need to care about this?

Swallowing errors silently is how bugs survive for months. In practice this is a scheduling problem more than a technical one. Budget a little time for it every quarter and it never becomes a project of its own.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. The cost of getting this wrong is rarely visible on the day it happens.

How do we know it is working?

Log enough context to reproduce without guessing. Getting it slightly wrong is survivable. Ignoring it entirely is not. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

How to tell if yours is fine

The question is rarely whether something can be built, but what it costs to keep running afterwards. 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.