error-handling-patternslisted

# Error Handling Patterns Errors are part of the contract, not an afterthought. A robust system **handles errors where it can act, propagates them where it can't, and never lets a failure vanish silently**. This skill is the deep reference: the decisions, the trade-offs, and the anti-patterns. Heavy detail lives in `references/`, copy-paste material in `examples/`, and a runnable linter for swallowed errors in `scripts/`. ## Mental model Every error sits on two axes that decide what you do with it: | Axis | Question | Consequence | |---|---|---| | **Operational vs programmer** | Is this an expected runtime condition (network down, bad input) or a bug (null deref, broken invariant)? | Operational → recover/retry/surface. Programmer → fail fast, let it crash, fix the code. | | **Recoverable vs fatal** | Can the caller do something useful about it here? | Yes → handle locally. No → add context and propagate. | Classifying wrong is the root cause of most bad error handling: retrying a programmer bug forever, or crashing the process over a single bad HTTP request. The full taxonomy is in [`references/error-taxonomy.md`](references/error-taxonomy.md). ## The five rules 1. **Validate at the boundary.** Reject bad input early with a clear, specific message (fail fast). Never trust data crossing a trust boundary — HTTP bodies, env vars, file contents, API responses. 2. **Classify the error.** Operational errors are values you handle; programmer errors are bugs you surface