Error Handling Patterns
Consistent, robust error handling patterns for production applications.
When to Activate
- Designing error types or exception hierarchies for a new module or service
- Adding retry logic or circuit breakers for unreliable external dependencies
- Reviewing API endpoints for missing error handling
- Implementing user-facing error messages and feedback
- Debugging cascading failures or silent error swallowing
Core Principles
- Fail fast and loudly — surface errors at the boundary where they occur; don't bury them
- Typed errors over string messages — errors are first-class values with structure
- User messages ≠ developer messages — show friendly text to users, log full context server-side
- Never swallow errors silently — every
catchblock must either handle, re-throw, or log - Errors are part of your API contract — document every error code a client may receive
TypeScript / JavaScript
Typed Error Classes
Result Pattern (no-throw style)
For operations where failure is expected and common (parsing, external calls):
API Error Handler (Next.js / Express)
React Error Boundary
Python
Custom Exception Hierarchy
FastAPI Global Exception Handler
Go
Sentinel Errors and Error Wrapping
Retry with Exponential Backoff
User-Facing Error Messages
Map error codes to human-readable messages. Keep technical details out of user-visible text.
Error Handling Checklist
Before merging any code that touches error handling:
- Every
catchblock handles, re-throws, or logs — no silent swallowing - API errors follow the standard envelope
{ error: { code, message } } - User-facing messages contain no stack traces or internal details
- Full error context is logged server-side
- Custom error classes extend a base
AppErrorwith acodefield - Async functions surface errors to callers — no fire-and-forget without fallback
- Retry logic only retries retriable errors (not 4xx client errors)
- React components are wrapped in
ErrorBoundaryfor rendering errors


