The Tablestore Python software development kit (SDK) handles errors using exceptions. This topic describes Tablestore error handling methods, exception information, and retry policies.
Method
The Tablestore Python SDK uses exceptions to handle errors. An API call is successful if no exception is thrown. If an exception is thrown, the operation has failed.
Batch operations such as BatchGetRow and BatchWriteRow are successful only if the system verifies that no exception is returned and the status of each row is successful.
Exceptions
The Tablestore Python SDK defines two types of exceptions: OTSClientError and OTSServiceError. Both inherit from the Exception class.
OTSClientError: Indicates an exception that occurred within the SDK, such as incorrect parameter settings or an error parsing the returned result.
OTSServiceError: Indicates a server-side error that is parsed from the server response. OTSServiceError contains the following members:
get_http_status: The HTTP return code, such as 200 or 404.
get_error_code: The error type string returned by Tablestore.
get_error_message: The error message string returned by Tablestore.
get_request_id: The universally unique identifier (UUID) that uniquely identifies the request. If you cannot resolve an issue, record this request ID and submit a ticket.
Retries
The SDK automatically retries an operation when an error occurs. By default, the maximum number of retries is 20 and the maximum retry interval is 3000 ms. The SDK retries throttling errors and server-side internal errors for read operations. For more information, see tablestore/retry.py.
To create a custom retry policy, you can inherit from the RetryPolicy class. When you initialize an OTSClient object, pass the custom retry policy as a parameter.
The SDK provides the following retry policies.
DefaultRetryPolicy: The default retry policy. It retries only read operations. The maximum number of retries is 20, and the maximum retry interval is 3000 ms.
NoRetryPolicy: No retries are performed.
NoDelayRetryPolicy: A retry policy with no delay. Use this policy with caution.
WriteRetryPolicy: Based on the default retry policy, this policy also retries write operations.