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