You wrapped the call in a try.
Something might fail,
and you knew it.
So you caught the exception,
wrote a line to the log,
and carried on.
That felt responsible.
It is not.
Handling an error means
the program now knows what to do.
Retry.
Fall back.
Tell the caller.
Stop.
Catch and log does none of those.
It makes the failure quiet
and lets the next line run
on data that never arrived.
The bug does not disappear.
It moves.
Three functions later
something is null,
and the stack trace points at code
that is entirely correct.
The line that actually broke
sits in a log file nobody reads,
at a level nobody alerts on,
timestamped forty minutes earlier.
You did not remove the problem.
You removed the evidence
and kept the problem.
Go and read your catch blocks.
Ask one question of each.
If this fires, what changes?
If the only answer is
that a line appears somewhere,
you have written a comment
with a runtime cost.
There are three honest options.
Handle it, which means you have
a second plan and you can name it.
Translate it, which means you wrap it
in something the layer above understands,
and you keep the original inside.
Or let it go up, untouched,
to whoever is in a position to decide.
That last one is the one
people are most afraid of
and need most often.
An empty catch is worse than all three.
But only slightly,
and at least it does not pretend.
Watch for the version
that hides behind a default.
Return zero.
Return an empty list.
Return the cached copy.
An empty list is a real answer
and a missing answer
wearing the same clothes,
and no caller alive
can tell them apart.
That is how a billing run
sends nothing to nobody
and reports success.
Errors are information.
A log line is not a plan.
It is a note to a future reader
who may never exist.
Decide what happens when it fails,
or let somebody above you decide.
Silence is a decision too.
It is just one you made
without telling anyone.
– Serguey Asael Shinder
