error-handling
Patterns for robust error handling across TypeScript, Python, and Go. Covers typed errors, error boundaries, retries, circuit breakers, and user-facing error messages. Use when designing error types, retries, circuit breakers, or user-facing failure messages in TypeScript, Python, or Go.
By affaan-m · 3,000 installs
npx skills add affaan-m/ecc --skill error-handling
Source repository · Upstream listing
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
1. Fail fast and loudly — surface errors at the boundary where they occur; don't bury them
2. Typed errors over string messages — errors are first class values with structure
3. User messages ≠ developer messages — show friendly text to users, log full context server side
4. Never swallow errors silently — every catch block must either handle, re throw, or log
5. 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 catch block 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 AppError with a code field
[ ] 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 ErrorBoundary for rendering errors