error-handlinglisted

# Error Handling ## Iron Law `ERRORS CARRY CONTEXT. NEVER CATCH WITHOUT HANDLING OR RE-RAISING.` ## When to Use - Designing or reviewing typed errors, exceptions, Result/Either flows, domain error boundaries, wrapping, retries, remote-call failures, panics, user-facing errors, or swallowed failures. ## When NOT to Use - Security-specific failure shape; pair with `security`. - REST status-code taxonomy or public API error schema; use `api`. - Observability of errors in production; pair with `observability`. ## Core Ideas 1. Failure is part of the function contract. 2. Add context at each boundary; preserve the original cause. Catch only where you can decide: recover, translate, retry, or terminate. 3. Translate failures when the caller's contract changes. Domain, infrastructure, API, CLI, and UI errors should not leak across boundaries unchanged. 4. Expected failures are typed: use named exception classes, discriminated unions, enums, or structured `Result` variants for recoverable cases. 5. Classify errors as user-correctable, transient, or programmer/system faults. 6. User-facing messages are safe and actionable; internal errors keep diagnostic detail under a correlation ID. 7. Remote calls declare timeout, retry, idempotency, and dependency-failure behavior together. Retry transient failures in one layer with a capped budget and jitter/backoff. 8. Panics/assertions are for impossible states and process boundaries, not routine contro