Error handling
Consistent error handling across frontend and backend layers. TRIGGER when: implementing error boundaries, exception handlers, or try/catch blocks. SKIP: shaping HTTP error response bodies (use api-design); logging the error (use logging-standards). (Examples in React + Python.)From its SKILL.md
npx -y skills add komluk/scaffolding --skill error-handlingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 15 stars15 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
5.1 KB, as published. Nobody here has run it
Error Handling Skill
Purpose
Standards for consistent error handling across frontend and backend layers (examples in React + Python).
Auto-Invoke Triggers
- Implementing exception handling
- Creating custom exceptions
- Handling API errors
- Implementing retry logic
- Designing user-facing error messages
Error Categories
| Category | HTTP Code | User Action | Log Level |
|---|---|---|---|
| Validation | 400 | Show field errors | WARN |
| Authentication | 401 | Redirect to login | WARN |
| Authorization | 403 | Show permission denied | WARN |
| NotFound | 404 | Show not found message | INFO |
| Conflict | 409 | Show conflict details | WARN |
| RateLimit | 429 | Show retry-after | WARN |
| ExternalService | 502 | Show fallback/retry option | ERROR |
| Internal | 500 | Show generic error | ERROR |
| Critical | 500 | Show maintenance page | CRITICAL |
Exception Hierarchy Design
Principles
- Create base
AppExceptionclass for all application errors - Extend with specific exception types per category
- Include: code, message, status code, details (optional)
- Never expose internal details to clients
Required Exception Types
ValidationException- Invalid input dataAuthenticationException- Auth token invalid/expiredAuthorizationException- User lacks permissionNotFoundException- Resource doesn't existConflictException- Resource state conflictRateLimitException- Too many requestsExternalServiceException- Third-party failure
Error Response Format
Standard Structure
{
"code": "ERROR_CODE",
"message": "Human-readable description",
"details": { "field": ["error1", "error2"] },
"correlationId": "abc-123"
}
Error Codes Convention
- Use SCREAMING_SNAKE_CASE
- Be specific:
USER_NOT_FOUNDnotNOT_FOUND - Group by domain:
AUTH_TOKEN_EXPIRED,AUTH_INVALID_CREDENTIALS
Frontend Error Handling
Principles
- Catch errors at API client level
- Transform to typed error objects
- Display user-friendly messages
- Log for debugging (not in production)
Error Boundary Rules
- Wrap major UI sections
- Provide fallback UI
- Log errors to monitoring service
- Allow recovery when possible
User Message Guidelines
- Be helpful, not technical
- Suggest actions user can take
- Don't blame the user
- Include support contact for critical errors
Backend Error Handling
Global Exception Handler
- Catch all unhandled exceptions
- Log with full context (path, method, user, correlation ID)
- Return standardized error response
- Never return stack traces in production
Exception Handling Rules
- Throw specific exceptions, catch specific exceptions
- Don't catch exceptions you can't handle
- Always re-throw or wrap caught exceptions
- Log at the boundary, not deep in code
What to Log
- Error type and message
- Request path and method
- User ID (if authenticated)
- Correlation ID
- Stack trace (for unexpected errors)
What NOT to Log
- Passwords or tokens
- Full request/response bodies with PII
- Credit card numbers
- Personal data (GDPR)
Retry Logic Standards
When to Retry
- Network timeouts
- 5xx server errors (external services)
- Rate limit (with backoff)
- Connection refused
When NOT to Retry
- 4xx client errors (except 429)
- Validation errors
- Authentication errors
- Non-idempotent operations (without idempotency key)
Retry Configuration
- Max attempts: 3
- Initial delay: 1 second
- Backoff multiplier: 2 (exponential)
- Max delay: 30 seconds
- Add jitter to prevent thundering herd
Circuit Breaker Pattern
Configuration
- Failure threshold: 5 failures
- Recovery timeout: 30 seconds
- Half-open max requests: 3
States
- Closed - Normal operation, requests pass through
- Open - Failures exceeded threshold, requests fail fast
- Half-Open - Testing if service recovered
Best Practices
DO
- Use specific exception types
- Include correlation IDs in all errors
- Log errors with context
- Return user-friendly messages
- Implement retry for transient failures
- Use circuit breaker for external services
DON'T
- Catch generic
Exceptionwithout re-throwing - Log sensitive data
- Return stack traces to clients
- Use exceptions for control flow
- Ignore errors silently
- Retry non-idempotent operations blindly
Quality Checklist
- All API endpoints return consistent error format
- Custom exceptions extend base exception class
- Global exception handler catches all unhandled exceptions
- Errors logged with appropriate level and context
- User messages helpful but don't leak internals
- Retry logic for external service calls
- Circuit breaker for cascading failure protection
- Correlation IDs tracked through entire request