In case of an Exception, when using the Cosmos DB "Async" API, we could simply catch the generic one and simply do an e.getCause() to see if the instance was of type DocumentClientException. However, when using the DocumentDB Sync, the chain seems to be lengthier. Is this expected ?
Ofcourse, we could use something like Apache common langs 'ExceptionUtils' to check the "Cause", but is this behavior deviation known ? I have a scenario to cast the exception based on the instance check and I use both Sync and Async separately for multiple stuff.
Example:
DocumentDB Sync API ADK:
java.lang.IllegalStateException: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: com.microsoft.azure.documentdb.DocumentClientException: Message: {"Errors":["Owner resource does not exist"]}
CosmosDB Async API SDK:
java.util.concurrent.ExecutionException: com.microsoft.azure.cosmosdb.DocumentClientException: Message: {"Errors":["Owner resource does not exist"]}
In case of an Exception, when using the Cosmos DB "Async" API, we could simply catch the generic one and simply do an e.getCause() to see if the instance was of type DocumentClientException. However, when using the DocumentDB Sync, the chain seems to be lengthier. Is this expected ?
Ofcourse, we could use something like Apache common langs 'ExceptionUtils' to check the "Cause", but is this behavior deviation known ? I have a scenario to cast the exception based on the instance check and I use both Sync and Async separately for multiple stuff.
Example:
DocumentDB Sync API ADK:
java.lang.IllegalStateException: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: com.microsoft.azure.documentdb.DocumentClientException: Message: {"Errors":["Owner resource does not exist"]}
CosmosDB Async API SDK:
java.util.concurrent.ExecutionException: com.microsoft.azure.cosmosdb.DocumentClientException: Message: {"Errors":["Owner resource does not exist"]}