Use when designing domain error handling. Keywords: domain error, error categorization, recovery strategy, retry, fallback, domain error hierarchy, user-facing vs internal errors, error code design, circuit breaker, graceful degradation, resilience, error context, backoff, retry with backoff, error

Domain Error Strategy Layer 2: Design Choices Core Question Who needs to handle this error, and how should they recover? Before designing error types: Is this user facing or internal? Is recovery possible? What context is needed for debugging? Error Categorization Error Type Audience Recovery Example User facing End users Guide action InvalidEmail , NotFound Internal Developers Debug info DatabaseError , ParseError System Ops/SRE Monitor/alert ConnectionTimeout , RateLimited Transient Automation Retry NetworkError , ServiceUnavailable Permanent Human Investigate ConfigInvalid , DataCorrupted Thinking Prompt Before designing error types: 1. Who sees this error? End user → friendly message, actionable Developer → detailed, debuggable Ops → structured, alertable 2. Can we recover? Transient → retry with backoff Degradable → fallback value Permanent → fail fast, alert 3. What context is needed? Call chain → anyhow::Context Request ID → structured logging Input data → error payload Trace Up ↑ To domain constraints (Layer 3): Question Trace To Ask Retry policy domain What's acceptable latency for retry? User experience domain What message should users see? Compliance domain What must be logged for audit? Trace Down ↓ To implementation (Layer 1): Quick Reference Recovery Pattern When Implementation Retry Transient failures exponential backoff Fallback Degraded mode cached/default value Circuit Breaker Cascading failures failsafe rs Timeout Slow operations tokio::time::timeout Bulkhead Isolation separate thread pools Error Hierarchy Retry Pattern Common Mistakes Mistake Why Wrong Better Same error for all No actionability Categorize by audience Retry everything Wasted resources Only transient errors Infinite retry DoS self Max attempts + backoff Expose internal errors Security risk User friendly messages No context Hard to debug .context() everywhere Anti Patterns Anti Pattern Why Bad Better String errors No structure thiserror types panic! for recoverable Bad UX Result with context Ignore errors Silent failures Log or propagate Box<dyn Error everywhere Lost type info thiserror Error in happy path Performance Early validation Related Skills When See Error handling basics m06 error handling Retry implementation m07 concurrency Domain modeling m09 domain User facing APIs domain

m13-domain-error