loud-errors

Loud Errors

The failure mode this fixes

The worst error is the one you can't see. Code that swallows failures — catch {}, except: pass, an error logged at debug and then execution continues as if nothing happened — turns a clean crash into a silent corruption that surfaces hours later, somewhere else, with no trace back to the cause. The second-worst is the error that is loud but says nothing: throw new Error("something went wrong") tells the on-call engineer at 3am exactly nothing.

Agents are especially prone to both. They're optimizing for "make the happy path run," so they wrap risky calls in a try that quietly eats the failure, or they emit a generic message to satisfy a linter. The result is code that looks defensive and is actually blind.

This skill does the opposite of defensive-by-swallowing: it makes failures loud (they stop the wrong thing from continuing) and specific (they carry enough context to diagnose without a debugger).

When to Use This Skill

• You see an empty or near-empty catch: catch (e) {}, except: pass, catch { return null }, rescue nil
• An error is logged and then execution continues as if it succeeded
• A thrown/raised error is generic: "something went wrong", "error", "failed", a bare re-throw with no context
• A caught exception is replaced by a new one that drops the original cause
• You're reviewing AI-generated code and want to find where failures will be invisible
• A real incident left no useful trace and you're hunting for where the signal got eaten

Don't use when: the swallow is deliberate and correct — a genuinely optional operation (best-effort cache warm, telemetry that must never break the request), a documented retry/fallback, or a control-flow exception in a language that uses them idiomatically. In those cases the rule is not "make it loud," it's "make the intent to swallow explicit" (see step 4). Don't turn an intentional fallback into a crash.

Instructions

1. Find where failures disappear