错误处理为Windows Azure存储迁移从1.7到2.0

我下面的代码更改：错误处理为Windows Azure存储迁移从1.7到2.0

try 
{ 
    blob.FetchAttributes(); 
} 
catch (StorageClientException e) 
{ 
    if (e.ErrorCode == StorageErrorCode.ResourceNotFound) 
     .... 
}

到：

try 
{ 
    blob.FetchAttributes(); 
} 
catch (StorageException e) 
{ 
    if (e.RequestInformation.ExtendedErrorInformation.ErrorCode == StorageErrorCodeStrings.ResourceNotFound) 
     .... 
}

后我运行它，它给了我一个NullException因为：

e.RequestInformation.ExtendedErrorInformation = NULL，

但是

e.RequestInformation.HTTPStatusMessage =“指定的blob不存在。”

和

e.RequestInformation.HTTPStatusCode = 404

我想，以测试HttpStatusMessage，但我觉得它是不是安全的做到这一点，因为消息可能会随时间而改变，任何人都可以帮助我在这种情况下我应该怎么做，如果我想保持我原来的逻辑行为？

来源

2013-03-25 Talen

ErrorCode在旧库中实际上与新库中的ErrorCode不同。旧库试图根据异常类型，HTTP状态代码和服务器返回的错误代码（如果有的话）对错误进行分类。在某些情况下，这会造成更多混淆，因为不同的错误被映射到单个值StorageErrorCode。

因此，在Azure存储客户端库2.0中，传统StorageErrorCode枚举不再存在。相反，我们要求我们的用户直接检查HTTP状态代码。如果服务器返回一个响应正文，该正文可以包含进一步的信息，如Status and Error Codes文章中所述。当这个数据存在时，ErrorCode将相应地填充。

在您的示例中，FetchAttributes发出Get Blob Properties请求，该请求不返回响应正文。这就是为什么ExtendedErrorInformation为空。

来源

2013-03-26 23:59:52

非常感谢您的帮助，因此为了检查服务器是否返回响应主体，我该怎么做？如果（e.RequestInformation.HTTPStatusCode！= 404）这个工作吗？ – Talen 2013-03-28 19:13:49

你实际上可以检查ExtendedErrorInformation属性本身。如果它不为空，则意味着服务器返回了一个包含更多错误信息的响应主体。然后你可以进一步调查发生了什么。 – 2013-03-29 05:34:09

错误处理为Windows Azure存储迁移从1.7到2.0

回答

相关问题