The Tablestore Java SDK throws exceptions to handle errors. This topic describes the error handling methods, exception details, and retry policies.
Method
If an API call does not throw an exception, the operation is successful. Otherwise, the operation failed.
For batch operations, such as BatchGetRow and BatchWriteRow, you must check for exceptions and verify the status of each row. The API call is considered successful only if all rows are processed successfully.
Exceptions
The Tablestore Java SDK includes two types of exceptions, ClientException and TableStoreException, both of which inherit from RuntimeException.
ClientException: An internal SDK exception, such as an exception caused by an incorrect parameter setting.
TableStoreException: A server-side error that is generated by parsing an error message from the server. A TableStoreException object contains the following members:
getHttpStatus(): The HTTP return code, such as 200 or 404.
getErrorCode(): The error code string returned by Tablestore.
getRequestId(): The universally unique identifier (UUID) that uniquely identifies the request. If you cannot resolve an issue, record this RequestId and submit a ticket.
Retry
The SDK automatically retries an operation if an error occurs. By default, the SDK retries only read operations that fail due to throttling errors or server-side internal errors. The default retry policy has a maximum retry duration of 10 s.
You can implement a custom retry policy by inheriting the RetryStrategy class and then pass the custom policy as a parameter when you construct the OTSClient object.
The following retry policies are implemented in the SDK:
DefaultRetryStrategy: The default retry policy. It retries only read operations. The retry interval increases exponentially starting from 10 ms, with a maximum retry duration of 10 s.
AlwaysRetryStrategy: Retries all types of requests up to three times. The retry interval increases exponentially starting from 4 ms, with a maximum interval of 1 s.