error-handling

Follow the 6-phase debugging protocol: collect evidence with verbose test output, form competing hypotheses (ACH), locate the exact file and line, fix all occurrences, re-run the failing test, then run the full suite to confirm zero regressions.

Use typed, domain-specific errors such as a Rust enum with thiserror or a Python exception hierarchy. Each error should include what failed, where, why, and actionable fix instructions rather than vague messages like "invalid input".

Combine retry with exponential backoff for transient failures and a circuit breaker to fast-fail when a downstream service is down. This prevents cascading failures and avoids overwhelming an already struggling dependency.

Fail fast for critical constraints like invalid config at boot, security violations, or data corruption risks. Degrade gracefully for auxiliary services like recommendations or analytics so users can still complete their primary task.

No. Production code should propagate errors with the ? operator and typed Results. unwrap() is acceptable only in tests and doc examples, and expect() only when failure is a logically impossible invariant violation.

Stack traces leak internal paths, queries, and implementation details to external actors. Return a generic message with a request ID to clients, and log the full trace securely in internal systems like CloudWatch or ELK.