Azure-cosmos-dotnet-v2: Use specialized exceptions instead of DocumentClientException everywhere

[RobertoPrevato]

Hi,
This is just a recommendation, a request for improvement.

Currently, all exceptions are handled using the same class: DocumentClientException. In order to understand the true nature of an exception, when using try-catch, is necessary to check the Message string property.

For example, to detect an exception thrown when a database doesn't exist:

catch (DocumentClientException dce) when (dce.Message.Contains("Owner resource does not exist"))

To detect an exception thrown when a collection doesn't exist inside a database:

catch (DocumentClientException dce) when (dce.Message.Contains("Resource Not Found"))

To detect an exception thrown when a query has invalid syntax:

catch (DocumentClientException dce) when (dce.Message.Contains("Syntax error"))

Even worse, the dce.Message is used to store details serialized in JSON format, prefixed with a "Message: " string. So, to get the root cause of a query syntax error, it's necessary to make some dull string operations to:

• check for "Syntax Error" inside the exception message
• cut the "Message: " prefix of exception message
• deserialize the resulting string
• read the "Message" property inside the deserialized dynamic object

It's unclear why specialized exceptions weren't defined, removing the need for exotic error messages containing JSON.
For example:

public class DatabaseNotFoundException : DocumentClientException {
   ...
}

public class QuerySyntaxException : DocumentClientException {
   ...
}

Best Regards,
Roberto Prevato

[kirankumarkolli]

@RobertoPrevato nice suggestion. Adding this to our backlog.

[Blackbaud-MichaelAndrews]

Gets even worse if you want to provide custom error details from a stored proc. You are forced to create a string of your details and throw an error with that. Your string is then buried in message: {"Errors": ["Encountered exception while executing function. Exception = Error" {your string}...

[ayngling]

I'd like to second the post about stored procedures. If instead of throwing a string I throw an object (to include an error code) I just get {"Errors": ["Encountered exception while executing function. Exception = Error" Exception = [object Object]... Being able to at least get the contents of what was thrown (be it a string or an object) from the DocumentClientException would be useful.

[admilazz]

I don't think we need specialized exception types for every error, but we do need some kind of error code describing what happened. When interacting with particular underlying APIs, we should also get error codes matching the standard error codes for that API. (E.g. when interacting with the MongoDB API, there should be a field giving the MongoDB error code, in addition to any CosmosDB error code you might add.) That way applications coming to CosmosDB can maintain their error handling logic.

It's just no good to have to look for strings inside of the exception message.

[JPhillipBrooks]

I'd also like to see some improvement in this area. I'm about to write a string parsing method just so I can extract my stored procedure error message that's buried deep within DocumentClientException.Message.