When error handling is worth the effort

This is cheap to get right at the start and expensive to retrofit. Error handling is not free, and pretending otherwise leads to bad decisions.

Most development decisions are really maintenance decisions wearing a different hat. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

When it is worth it

Swallowing errors silently is how bugs survive for months. It is worth being explicit about, because assumptions differ quietly. If two people in the business would answer this differently, that gap is the actual problem.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. Getting it slightly wrong is survivable. Ignoring it entirely is not.

How to decide

Log enough context to reproduce without guessing. Small and consistent beats large and occasional here. It rarely shows up as a line item, which is exactly why it slips.

In practice

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
• 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.