How to get error handling right
It is rarely the thing that gets a project approved, and often the thing that decides how it goes. The short answer to error handling is that it is mostly a sequence of small decisions, not one big one.
Most development decisions are really maintenance decisions wearing a different hat. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
Why it matters
Swallowing errors silently is how bugs survive for months. Getting it slightly wrong is survivable. Ignoring it entirely is not. It is the sort of thing that looks like polish right up until it costs you an enquiry.
The steps
- Establish what you have today before changing anything
- Fail loudly in development, gracefully in production
- Log enough context to reproduce without guessing
- Write down the decision so the next person does not re-litigate it
Log enough context to reproduce without guessing. 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.
What to do next
The short version
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
- 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
Most of the value here comes from doing the first two things, not all of them.