Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
[{"error_context":"Where and how errors occur (API, database, UI, third-party service)"},{"reliability_requirement":"How critical is this operation (best-effort vs. must-succeed)"},{"user_impact":"How errors affect the end user"}]
outputs
[{"error_strategy":"Comprehensive error handling approach"},{"retry_policy":"When and how to retry failed operations"},{"fallback_plan":"Degradation path when retries are exhausted"},{"error_types":"Typed error hierarchy for the system"},{"user_communication":"How to present errors to users"}]
linksTo
["logging","api-designer","ui-ux-pro"]
linkedFrom
["orchestrator","planner","code-architect"]
preferredNextSkills
["logging","api-designer"]
fallbackSkills
["sequential-thinking"]
riskLevel
low
memoryReadPolicy
selective
memoryWritePolicy
selective
sideEffects
[]
Error Handling
Purpose
This skill provides systematic approaches to handling errors across the entire stack — from database operations through API layers to user interfaces. It covers error classification, retry strategies, circuit breakers, graceful degradation, and the critical art of communicating errors to users without exposing internal details.
Key Concepts
Error Classification
Every error falls into one of these categories, and each demands a different response:
TRANSIENT (retry-safe):
- Network timeout
- Database connection pool exhaustion
- Rate limit (429)
- Service temporarily unavailable (503)
- DNS resolution failure
RESPONSE: Retry with exponential backoff
PERMANENT (do NOT retry):
- Validation error (400)
- Authentication failure (401)
- Authorization failure (403)
- Resource not found (404)
- Business rule violation (409/422)
RESPONSE: Return error to caller immediately
BUG (should never happen in production):
- Null pointer / undefined access
- Type mismatch
- Assertion failure
- Out of bounds
RESPONSE: Log with full context, alert, return 500
CATASTROPHIC (system-level):
- Out of memory
- Disk full
- Cascading failure
- Data corruption
RESPONSE: Alert immediately, activate fallback, page on-call
The Error Handling Hierarchy
LEVEL 1 — PREVENT: Design errors out of the system
- Type safety (TypeScript strict mode)
- Input validation at boundaries
- Database constraints (NOT NULL, UNIQUE, FK, CHECK)
- Compile-time checks over runtime checks
LEVEL 2 — DETECT: Catch errors as close to the source as possible
- Try/catch at integration boundaries
- Error boundaries in React components
- Health checks for dependencies
- Schema validation at API entry points
LEVEL 3 — RECOVER: Automatically recover when possible
- Retry transient failures
- Fall back to cached data
- Degrade gracefully (show partial results)
- Redirect to alternative service
LEVEL 4 — REPORT: Make errors visible and actionable
- Structured logging with context
- Error tracking (Sentry, Datadog)
- Alerting for critical errors
- User-facing error messages
LEVEL 5 — LEARN: Prevent recurrence
- Post-incident reviews
- Automated tests for discovered bugs
- Monitoring improvements
- Runbook updates
Patterns
Pattern 1: Result Type (Errors as Values)
Instead of throwing exceptions, return errors as values:
1. NEVER expose internal details (stack traces, SQL errors, file paths)
2. ALWAYS provide an actionable next step
3. USE human language, not error codes (show codes as secondary reference)
4. DIFFERENTIATE between "your mistake" and "our mistake"
5. PRESERVE user's work (don't clear forms on error)
Error Message Templates
USER INPUT ERROR:
Title: "We couldn't process your request"
Body: "[Specific field] [specific problem]. [How to fix it]."
Example: "The email address isn't valid. Please check for typos and try again."
Action: [Fix the field and retry]
AUTHENTICATION ERROR:
Title: "Please sign in to continue"
Body: "Your session has expired. Please sign in again to continue where you left off."
Action: [Sign in button → return to current page]
PERMISSION ERROR:
Title: "Access restricted"
Body: "You don't have permission to [action]. Contact your organization admin for access."
Action: [Contact admin link / Go back]
NOT FOUND:
Title: "Page not found"
Body: "The page you're looking for doesn't exist or has been moved."
Action: [Go to homepage / Search / Go back]
SERVER ERROR:
Title: "Something went wrong"
Body: "We're having trouble processing your request. Please try again in a few moments."
Action: [Retry button] [Contact support link]
Subtext: "Reference: [requestId] — share this with support if the problem persists."
SERVICE UNAVAILABLE:
Title: "We're briefly offline for maintenance"
Body: "We'll be back shortly. Check our status page for updates."
Action: [Status page link] [Auto-refresh countdown]
Pokemon exception handling: catch (e) {} — catching and ignoring errors hides bugs and causes silent data corruption.
Logging and rethrowing without context: catch (e) { log(e); throw e; } adds noise. Either handle it or let it propagate.
User-facing stack traces: Exposing Error: ECONNREFUSED 127.0.0.1:5432 tells attackers about your infrastructure and confuses users.
Retrying non-retryable errors: Retrying a 400 Validation Error will fail forever. Only retry transient errors.
Unbounded retries: Retrying without a limit or backoff causes thundering herd problems and amplifies outages.
Error handling as control flow: Using try/catch for expected conditions (like "user not found") instead of checking first. Reserve exceptions for exceptional situations.
Integration Notes
Use logging to ensure all errors are captured with sufficient context for debugging.
Use api-designer to define consistent error response contracts across all endpoints.
Use ui-ux-pro to ensure error states in the UI meet visual standards and accessibility requirements.
Hand off to sequential-thinking when debugging complex error chains.