Before you invest in error handling
The gap between knowing this and actually doing it is where most teams lose ground. Before you spend anything on error handling, it is worth confirming a few things are already true.
Most development decisions are really maintenance decisions wearing a different hat. Check it against what you would want a competitor's site to get wrong.
Prerequisites
- You can describe the outcome you want in one sentence
- Someone owns it after the work is done
- Swallowing errors silently is how bugs survive for months
- You have a way to tell whether it worked
Where it usually goes wrong
Fail loudly in development, gracefully in production. Small and consistent beats large and occasional here. Budget a little time for it every quarter and it never becomes a project of its own.
Log enough context to reproduce without guessing. It is worth being explicit about, because assumptions differ quietly. Check it against what you would want a competitor's site to get wrong.
What this looks like day to day
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.