🚨 Error Handling
Comprehensive error handling with onError hook, error mapping, and custom error modification.
Z-Fetch provides comprehensive error handling capabilities that intercept all error types and allow you to customize error messages and behavior throughout your application.
Error Types Covered
The error handling system captures:
- HTTP errors (4xx/5xx status codes)
- Network errors (connection failures, DNS issues)
- Timeout errors (request timeouts → status:
TIMEOUT, message:"Request timed out!") - Cancellation (user-initiated abort → status:
CANCELED, message:"Request canceled") - Parse errors (invalid JSON responses)
- Request errors (malformed requests)
Complete Coverage
The onError hook provides comprehensive error coverage and modification capabilities for better user experience.
Cancellation and Timeout
Z-Fetch standardizes cancellation and timeouts across both fetch and XHR paths:
- Cancellation (manual abort) yields
error.status = 'CANCELED'anderror.message = 'Request canceled'. - Timeout (exceeding configured
timeout) yieldserror.status = 'TIMEOUT'anderror.message = 'Request timed out!'. - Error mapping does not override cancel/timeout messages by default.
onError Hook
The onError hook intercepts all errors and allows you to modify them:
Error Context
The onError hook receives a comprehensive context object:
Error Handling Modes
Z-Fetch supports two error handling modes to suit different coding styles:
Default Mode (throwOnError: false)
By default, errors are returned in result.error rather than thrown. This is safer and prevents unexpected crashes:
Throwing Mode (throwOnError: true)
Enable throwOnError for traditional try-catch error handling:
Choose What Fits Your Style
Default mode is safer and more explicit. Throwing mode is familiar to developers coming from fetch/axios. Both modes work with all features: error mapping, hooks, retries, and caching.
throwOnError with Retries
throwOnError works seamlessly with retry logic. Errors won't be thrown during retry attempts - only after all retries are exhausted:
How it works:
- During retry attempts, errors are not thrown
- If a retry succeeds,
result.erroris cleared and success data is returned - Errors are only thrown after all retry attempts are exhausted
- This ensures retry logic can work properly without interruption
Error Modification
Using setError Helper
Using Return Values
Error Mapping
By default, error mapping only applies to z-fetch internal errors. You can optionally enable it for backend HTTP errors.
Default: Map Z-Fetch Internal Errors Only
Optional: Map Backend HTTP Errors
Enable mapErrors: true to also map backend HTTP status codes:
Backend Error Mapping is Optional
By default (mapErrors: false), only z-fetch internal errors (NETWORK_ERROR,
TIMEOUT, CANCELED) are mapped. Backend HTTP errors use the original
response.statusText, allowing your backend to control error messages. Set
mapErrors: true to enable mapping for backend errors too.
Pattern Matching
Error mapping supports flexible pattern matching:
Real-World Examples
Authentication Error Handling
Retry Logic with Error Handling
User-Friendly Error Messages
Error Logging and Tracking
Integration with Error Mapping
The onError hook works alongside error mapping:
Error Recovery Patterns
Fallback Data
Graceful Degradation
Error Hook Best Practices
Comprehensive Logging: Always log errors for debugging User-Friendly Messages: Provide clear, actionable error messages Error Classification: Categorize errors for better handling Context Preservation: Keep original error information Recovery Options: Provide fallback data when possible Security: Don't expose sensitive error details to users
Related Features
Error handling works seamlessly with other Z-Fetch features:
- 🟡 Streaming Support - Comprehensive error handling for streaming operations
- ⭐ Progress Tracking - Error handling for upload/download operations
- 💪 Using Hooks - Enhanced hooks system with onError hook for request lifecycle management
- 👉 Request Methods - All HTTP methods support comprehensive error handling