Error handling

更新时间:
复制 MD 格式

The Tablestore PHP software development kit (SDK) handles errors by throwing exceptions. This topic describes Tablestore error handling, exception information, and retry policies.

Method

The Tablestore PHP SDK handles errors by throwing exceptions. If an API call completes without an exception, the operation was successful. Otherwise, it failed.

Note

For batch operations, such as BatchGetRow and BatchWriteRow, you must check for exceptions and also check the status of each row. The entire API call is considered successful only if all rows are processed successfully.

Exceptions

The Tablestore PHP SDK defines two types of exceptions: OTSClientException and OTSServerException. Both exceptions inherit from the base Exception class.

  • OTSClientException: An exception that occurs within the SDK, for example, if a parameter is set incorrectly.

  • OTSServerException: A server-side error that is parsed from the error message returned by the server. An OTSServerException object contains the following members:

    • getHttpStatus(): The HTTP return code, such as 200 or 404.

    • getOTSErrorCode(): The error type string returned by Tablestore. For more information about common errors, see Error codes.

    • getOTSErrorMessage(): The detailed error description 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 or join the DingTalk group 36165029092 (Tablestore Technical Support Group 3) for assistance.

Retries

  • The SDK automatically retries operations when an error occurs. The default policy is to retry a maximum of 3 times with a maximum retry interval of 2000 ms. For more information, see Retry.

  • You can also customize the retry policy by modifying the RetryPolicy in OTSClientConfig.

The SDK implements the following retry policies:

  • DefaultRetryPolicy: The default retry policy. This policy retries an operation up to 3 times with a maximum retry interval of 2000 ms. It applies to throttle-related errors and server-side internal errors for read operations.

  • NoRetryPolicy: No retries are performed.