Our error rate dropped to zero overnight. We hadn't fixed anything. We'd added a try/catch that swallowed every failure.
Never catch an exception without deciding what happens to that information. A quiet catch block deletes the only signal something is broken.
observabilitycorrectness
Problem
Our monitoring dashboard showed a perfect night: error rate at zero for the first time in months. Nobody had shipped a fix. What we’d actually shipped, three days earlier, was a try/catch wrapped around a payment retry helper, added to stop a noisy alert from paging someone at 2am.
Why it happens
Swallowing an exception feels like solving the problem: the alert stops, the dashboard turns green, everyone moves on. But the exception was information, not noise. Once the catch block eats it silently, you lose the only signal that something downstream is broken, and you don’t find out until a customer does.
Better approach
Never catch an exception without deciding, explicitly, what happens to that information. If you don’t want to page someone at 2am, that’s a monitoring/severity problem, not a reason to delete the error. Log it, tag it, downgrade its alert priority, but let it surface somewhere a human can see the trend.
Example
We eventually found the payment retries had been silently failing for nine days. Customers who hit that path were quietly being charged twice, and support tickets, not our dashboard, were the only place it showed up.