2026-05-21 · Vericode Team · 6 min read
An empty `catch` is a decision to lie. The operation failed, the program continues, and the next function treats missing data as success. Users see yesterday’s cart, a blank chart, or a “saved” toast that never reached the server.
Teams add these blocks to “keep the app from crashing” during a demo. The crash was information. Replacing it with silence converts a loud defect into a support ticket two weeks later. Prefer a fallback that is visible: a retry, a banner, or a degraded read-only state.
Logging inside a catch is not automatically better. `console.error(e)` in a browser tab nobody watches is still a silent failure from the user’s point of view. Pair the log with a user-visible outcome and, in production, a destination a human will see.
The same pattern shows up without `catch`: functions that return `null` on every error, `|| []` that hides a broken fetch, or `then(() => {})` on a promise. Search your codebase for these. They are empty-catch blocks with better manners.
Type systems do not save you if you erase the error. `unknown` in a catch that is immediately ignored is ceremony. Model the failure: a result type, an error code, or an exception that a boundary is required to handle.
Reviews should treat swallowed errors as severity-worthy. Vericode’s review templates call out leftover TODOs and unsafe sinks; your human pass should call out empty handlers the same way. Ask: what should the user see, and what should we measure?
When you must continue after a failure — a best-effort analytics ping, for example — write why it is safe to continue. That comment is not narration. It is a contract that the failure does not affect the user’s data.
If you inherit a file full of silent catches, do not boil the ocean. Replace them at the boundary you are already touching. One honest error path in the function you shipped today is worth more than a stylistic cleanup of files you did not run.