The Quicksilver SDK provides a robust and type-safe error handling mechanism to help developers gracefully manage various issues that may arise during API interactions. All SDK-specific errors derive
The Quicksilver SDK provides a robust and type-safe error handling mechanism to help developers gracefully manage various issues that may arise during API interactions. All SDK-specific errors derive from a common base class, QuicksilverError, allowing for flexible and granular error management.
QuicksilverError is the foundational error class for all exceptions thrown by the Quicksilver SDK. It provides common properties like statusCode and details to give more context about the error.
The SDK defines several specific error classes that extend QuicksilverError, representing different categories of problems. These are primarily generated by the SDK's HttpClient based on HTTP response codes and network conditions.
Thrown when the Quicksilver API successfully responds with a non-2xx HTTP status code and includes a structured error payload. This class wraps the raw API error details.
When it's thrown: For specific API-level errors where the server explicitly returns an error message and status, e.g., trying to create an account with an invalid account_type.
Thrown when there's an underlying network connectivity problem, preventing the request from reaching the API or receiving a response.
When it's thrown: For issues like a disconnected internet connection, DNS resolution failure, a server being unreachable, or a request timing out.
Thrown when an API request fails due to invalid, expired, or missing API credentials.
When it's thrown: Typically for an HTTP 401 Unauthorized response, indicating an issue with the provided API key.
Thrown when a requested resource (e.g., an account, a transaction, a stream) cannot be found on the server.
When it's thrown: For an HTTP 404 Not Found response, when you try to retrieve, update, or delete a resource that does not exist.
Thrown when a request payload is syntactically correct but semantically invalid, failing server-side business logic or data validation rules.
When it's thrown: For an HTTP 400 Bad Request response, when the data sent in the request does not meet the expected format or constraints (e.g., negative amount, invalid currency format).
Thrown when the client has exceeded the API's rate limits, sending too many requests within a specified time window.
When it's thrown: For an HTTP 429 Too Many Requests response. It may include a retryAfter property in its details if the API provides it, indicating how long to wait before retrying.
Thrown for unexpected errors occurring on the Quicksilver API server itself, indicating a problem with the service rather than the request.
When it's thrown: For HTTP 5xx responses (e.g., 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout).
To effectively handle errors in your application, use try...catch blocks and catch the specific error types you anticipate. Catching more specific errors first allows for targeted recovery logic, while a final QuicksilverError or generic Error catch can handle unexpected issues.
By leveraging the SDK's structured error classes, you can build more resilient and user-friendly applications that gracefully handle the complexities of financial operations.