Error hierarchy
Quick example
Error types
ApiError
ApiError
Thrown for HTTP error responses (4xx, 5xx).Common status codes:
| Code | Meaning | Action |
|---|---|---|
| 400 | Bad Request | Check request parameters |
| 401 | Unauthorized | Check credentials |
| 403 | Forbidden | Check permissions |
| 404 | Not Found | Resource doesn’t exist |
| 429 | Too Many Requests | Implement rate limiting |
| 500 | Server Error | Retry or contact admin |
ValidationError
ValidationError
Thrown when response data doesn’t match expected Zod schema.Example:
NetworkError
NetworkError
Thrown for connection failures, DNS errors, etc.Common causes:
- Server not reachable
- DNS resolution failed
- Connection refused
- SSL/TLS errors
TimeoutError
TimeoutError
Thrown when a request exceeds the configured timeout.
Type guards
Always use type guards for safe error handling:Handling patterns
Graceful 404 handling
Retry logic
- Simple retry
- With rate limiting
Centralized error handler
Error transformation
Transform SDK errors to your app’s error types:Client-side retry configuration
Configure automatic retries at the client level:Testing error handling
Full reference
For detailed error class APIs, seesrc/errors/README.md in the SDK repository.
Next steps
Configuration
Configure retry behavior at the client level.
Best Practices
Error handling patterns for production.