locked
3 Azure exception classes? StorageException, StorageClientException & StorageServerException RRS feed

  • Question

  • That makes sense.  My intention is to keep all account related entities in the Accounts table except for the public users for the reasons specified.

    On a separate note I've noticed that there are 3 Azure exception classes (StorageException, StorageClientException & StorageServerException) but haven't been able to find much guidance on which to use when handling Azure exceptions and the MS doco is kind of sparse.  Do you happen to have any insight on these and when or when not to use them?

    Thanks again for the replies. It is most appreciated.

    • Split by BrentDaCodeMonkey Thursday, February 2, 2012 7:06 PM start new thread for new question
    Wednesday, February 1, 2012 3:35 AM

Answers

  • Hi again - can I ask you to post that question on a new thread?  That will make it easier for people in the future with the same question.  I'm preparing a response for now, and will post it when I see the new thread.  Thanks!


    -Jeff
    • Marked as answer by Arwind - MSFT Tuesday, February 7, 2012 8:12 AM
    Thursday, February 2, 2012 6:56 PM

All replies

  • Hi again - can I ask you to post that question on a new thread?  That will make it easier for people in the future with the same question.  I'm preparing a response for now, and will post it when I see the new thread.  Thanks!


    -Jeff
    • Marked as answer by Arwind - MSFT Tuesday, February 7, 2012 8:12 AM
    Thursday, February 2, 2012 6:56 PM
  • Jeff and Stoolio, I've gone ahead and split the thread for the new question. Apologies if this wasn't appropriate.
    Thursday, February 2, 2012 7:07 PM
  • Thanks for creating a new thread.  I should have thought of that myself.  My bad.
    Thursday, February 2, 2012 8:02 PM
  • As you mentioned, in the StorageClient we define three exception types, StorageExceptino, StorageClientException, and StorageServerException. The rationale behind it has to due with how the library handles errors and potentially retries. 

    StorageException - Exception base type, both client and server exceptions derive from this.

    StorageClientException - Something the client did caused a failure - this could be bad request, condition not met, container not found etc.  Retrying the operation will not help.

    StorageServerException - Something that occurred on the server caused a failure - Server internal error, operation timed out, serverbusy, md5 mismatch etc.  These operations will be retried according to the specified RetryPolicy (Default is 3 more attempts using an exponential backoff). Typically if the client catches this exception it means the last attempted operation resulted in a Server exception.

    Internally the way things work to determine if an operation is retryable is:

    1. Client side timeouts are always retried ( server doesnt resond timely, slow edge connection etc)
    2. A server exception with http status !=501/505 will be retried
    3. A InvalidOperationException (WebException derives from this) with http status code that is 4xx, 501, 505 will NOT be retried, otherwise it will.

    From the clients perspective it is safe to catch StorageException since this defines the http status code, message, and extended information. However if you wish to recover in a different way you may catch the derived types.

    Hopefully this helps, we are in the process of updating the MSDN docs to shed more clarity on this topic. 

    Joe Giardino

    Wednesday, February 8, 2012 7:55 PM