error-handling

Topics in the source

• Error Handling Patterns
• When to Activate
• Core Principles
• TypeScript / JavaScript
• Typed Error Classes
• Result Pattern (no-throw style)
• API Error Handler (Next.js / Express)
• React Error Boundary

Consistent, robust error handling patterns for production applications. 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 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 For operations where failure is expected and common (parsing, external calls): Map error codes to human-readable messages. Keep technical details out of user-visible text. 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, messag

This is an excerpt. Refer to the complete source and its current requirements.