error-handling-patterns

# Error Handling Patterns Apply consistent patterns for throwing, catching, logging, and surfacing errors so failures are predictable and debuggable without leaking internals. ## When to Activate - Implementing or refactoring error handling in an API or app - User asks for "error handling", "how to handle errors", or "consistent errors" - Reviewing code for proper failure handling - Defining or documenting error contract for a service or API ## Core Principles - **Operational vs programmer errors** — Classify first. Operational failures (network timeout, invalid input, missing record) are expected: handle, retry, or surface them. Programmer errors (undefined access, broken invariant) are bugs: crash loudly or restart the process rather than limping on with corrupted state. - **Make the bug impossible, not just fixed** — A single-point fix stops one path; defense in depth stops the class. For a high-value invariant, guard it at more than one layer: validate at the entry point, re-check in the business logic, add environment/config guards, and instrument for the failure. Then test that bypassing an outer layer still gets caught by an inner one (deliberately skip Layer 1, verify Layer 2 catches it; confirm mocks don't silently disable a validation). - **Fail fast** — Validate inputs and preconditions early; throw or return errors with clear messages. Do not continue with invalid state. - **Do not swallow** — Avoid empty catch or broad catch that ignores; log and/or rethrow ...