Error Handling
Scope: Always appliedRule ID:
hatch3r-error-handling
Defines error handling patterns including structured error hierarchies, retry strategies with exponential backoff, and correlation tracking across client and server.
Structured Error Hierarchy
Base Error Class
Domain-Specific Error Classes
Never Throw Raw Errors
Error Code System
Typed Error Codes
Map Error Codes to HTTP Status
Never Swallow Errors
Always Re-throw or Log
Retry with Exponential Backoff
Retry Strategy for Transient Failures
Honor Retry-After on 429
API Error Responses
Structured Error Response Format
Never Expose Internal Details
UI Error Boundaries
Framework Error Boundaries
User-Friendly Fallback UI
- Display a clear, actionable error message
- Provide recovery actions (retry, refresh, contact support)
- Log full error details server-side
- Never show stack traces or technical details to users
Correlation ID Tracking
Generate and Propagate Correlation IDs
Client-Side Correlation
Security: No Secrets in Errors
Sanitize Error Messages
Sanitize Logs
Enforcement
Code review checklist:- All errors use domain-specific error classes (no raw
Error) - Error codes are typed string enums
- No swallowed errors (all caught errors are logged or re-thrown)
- Retry logic uses exponential backoff
- API responses use structured error format
- Correlation ID included in all error logs
- No secrets, tokens, or PII in error messages or logs
- Lint rule: detect
throw new Error()without using AppError - Test coverage: verify error handling paths are tested
Related Rules
- Code Standards — Result types and error boundaries
- Observability — Structured logging and correlation
- Security Patterns — Sanitization and fail-closed defaults

