Handling Windows Azure Storage Exceptions

Ever wonder how to figure out what’s gone wrong with your calls to Windows Azure Storage?

The Windows Azure Storage Team has created a StorageException that contains information about what has gone wrong. The example below tries to acquire a lease on a blob to illustrate how you can catch and handle Windows Azure Storage Exceptions.

public string TryAcquireLease(CloudBlobContainer container, TimeSpan leaseTime)
{
    try
    {
        return container.AcquireLease(leaseTime, null);
    }
    catch (StorageException ex)
    {
        var requestInformation = ex.RequestInformation;

        Trace.WriteLine(requestInformation.HttpStatusMessage);

        // get more details about the exception
        var information = requestInformation.ExtendedErrorInformation;

        // if you have aditional information, you can use it for your logs
        if (information == null)
            throw;

        var errorCode = information.ErrorCode;

        var message = string.Format("({0}) {1}",
            errorCode,
            information.ErrorMessage);

        var details = information
                        .AdditionalDetails
                        .Aggregate("", (s, pair) =>
                        {
                            return s + string.Format("{0}={1},", pair.Key, pair.Value);
                        });

        Trace.WriteLine(message + " details " + details);

        switch (information.ErrorCode)
        {
            // (409) Conflict  
            // "There is already a lease present."
            case "LeaseAlreadyPresent":
                // throw a user defined exception
                throw;

            // (404) Not Found  
            // The specified container does not exist.
            case "ContainerNotFound":
                // throw a user defined exception
                throw;

            default:
                // throw a user defined exception for unknown code
                throw;
        }
    }
    catch (Exception ex)
    {
        // throw a user defined exception
        // and treat generic exception
        throw;
    }
}

On MSDN it’s not recommended to use the contents of the Extended Error Information to build error handling logic. The Windows Azure Storage Team has overridden ExtendedErrorInformation, which is accessible through the RequestInformation property of the StorageException. Since the Extended Error Information is not guaranteed to propagate properly, I recommend catching and handling Storage Exceptions as early as possible. 

An Exert From MSDN About “Extended Error Information”

Extended error information is not reliable. Extended error information cannot be used for building code logic. It is appropriate to check for the presence of extended error information, and if there, to dump, save, or log that information. But do not rely on the information or its contents.

The following reasons explain why extended error information is not reliable:

• The sequence and contents of the extended error records depends on the internal architecture of the system, which is subject to change. A certain operation may go through NPFS on current systems, but tomorrow could go through TCP. These different components generate very different error codes, and code checks therefore are inherently unreliable and not recommended.
• The propagation of extended error information can be disabled, as explained previously. If detection code is included, the application will likely stop working in certain environments.
• The propagation of extended error information is performed in a best effort manner. Propagation or generation of extended error information can fail if there isn’t enough memory on the computer to process or propagate the chain. Under such circumstances, the chain will be dropped. Some protocols have limited lengths for fault packets since they usually don’t include much information. If the length of the chain exceeds the allowed length of the packet, the RPC run time begins dropping information from the chain in an attempt to fit the chain into the packet. The run time first drops records, starting from the penultimate record, going backwards, until only the first and last records remain. If the chain still doesn’t fit into a packet, the run time drops string parameters and computer names. If a string parameter is dropped, the type of the parameter is set to none. If a record is dropped, the EEInfoNextRecordsMissing flag is set in the next record, and EEInfoPreviousRecordsMissing is set in the previous record.

Source: Reliability of Extended Error Information

Once you’ve identified what has gone wrong, I strongly recommend throwing your own exceptions. Don’t reuse existing system exceptions, because they usually do not convey enough context. Using your own exceptions will also allow you to use them to clearly communicate the responsibility of each catch block.

Status and Error Code References

Use the following links to find errors codes for each service. These can help fine tune and respond properly to exceptions thrown by the Windows Azure Storage Client.

• Status and Error Codes
• Common REST API Error Codes
• Blob Service Error Codes
• Queue Service Error Codes
• Table Service Error Codes