2013-01-16 2 views
9

WindowsAzure.StorageClient 1.7からWindowsAzure.Storage 2.0に移行していますが、現在は例外の管理に取り組んでいます。このguideおよび他のソースに続いて、私はWindowsAzure.Storage v2 StorageException

try 
{ 
    // Something 
} 
catch (StorageException e) 
{ 
    switch (e.RequestInformation.ExtendedErrorInformation.ErrorCode) 
    { 
     case StorageErrorCodeStrings.ContainerNotFound: 
     case StorageErrorCodeStrings.ResourceNotFound: 
     case BlobErrorCodeStrings.BlobNotFound: 
     case StorageErrorCodeStrings.ConditionNotMet: 
      // Do something 
    } 
} 

は、単純なルックスに

try 
{ 
    // Something 
} 
catch (StorageClientException e) 
{ 
    switch (e.ErrorCode) 
    { 
     case StorageErrorCode.ContainerNotFound: 
     case StorageErrorCode.ResourceNotFound: 
     case StorageErrorCode.BlobNotFound: 
     case StorageErrorCode.ConditionFailed: 
      // Do something 
    } 
} 

から移行しなければならなかったが分かりました。 問題はExtendedErrorInformationが常にnullと等しいことです。代わりに、HttpStatusMessageは '指定されたBLOBは存在しません'と言います。

私はそれがテスト環境のシミュレータに起因すると思っていましたが、実際のAzure環境で試してみると同じ状況になりました。

+0

文書によると、拡張エラー情報はコードlogiに依存してはなりませんc - http://msdn.microsoft.com/en-us/library/windows/desktop/aa375374%28v=vs.85%29.aspx –

+0

@RussCamこのリンクは、ストレージクライアントAPIではなくRPCに関するものと思われます。 – fsimonazzi

答えて

3

私はそれを試しましたが、実際にはExtendedErrorInformationオブジェクトがnullであることに驚いていました。しかし、必ずしもnullではありません。たとえば、blobContainer.Create()メソッドを使用して既に存在するBLOBコンテナを作成しようとすると、null以外のExtendedErrorInformationが取得されます。しかし、BLOBコンテナに存在しないBLOBの属性を取得しようとすると、null ExtendedErrorInformationオブジェクトが取得されます。私は、ExtendedErrorInformationオブジェクトが常に利用可能であると仮定することはできません。

また、2.0用のコードでStorageErrorCodeStringsを使用していることに気付きました。 2.0から削除され、バージョン1.8以前でのみ利用可能であることに注意してください。私はそれを言及すべきだと思った。

更新:@ VollmonDの下のコメントをご覧ください。これはバージョン2.0.3で追加されました。

+1

StorageErrorCodeStringsが2.0.3で追加されました。パッケージをnuget経由で入手しました。 FetchAttributesは、問題が発生した状況の1つです。今私は、エラーメッセージを取得し、それをHttpStatusと比較するためにエラーコード文字列を使用できるかどうかを確認しようとしています。あなたのブログのエントリをありがとう、それはこれらの移行日中に私を助けた:) –

+0

私の悪い!私は、ストレージチームにこれが含まれていることを知らなかった。私は戻って例外処理のポストを更新する必要があります:)。私はあなたが私のブログの投稿を気に入ってうれしいです。 –

6

もう1つの方法は、代わりにRequestInformation.HttpStatusCodeを見ることです。これはとにかくより信頼できるようです。パーティーに後期

try 
{ 
    // Something 
} 
catch (StorageException e) 
{ 
    switch (e.RequestInformation.HttpStatusCode) 
    { 
     case (int)HttpStatusCode.NotFound: 
     case (int)HttpStatusCode.PreconditionFailed: 
     // Do something 
    } 
} 
+0

はい、私はその状態コードを知っていましたが、私の目的にとってはあまりにも一般的です。 Azureのエラーコード文字列によって与えられた '力'が必要でした。私はHttpStatusMessageから文字列を取り出し、それをAzureコードと比較してコードを返しました。他の回答の@Gauravは正しかった、問題はFetchAttributesだけで、私が見たことがあります。 –

0

、しかし、あなたは、彼らが(拡張メソッドちょっとアプローチを)存在する場合ブロブから項目を削除するか、単にチェックを扱うようにしようとしている場合:あなたのコードはに比較的容易に変換されます。あなたが今使用することができ :

チェック:https://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storage.blob.cloudblockblob.aspx

関連する問題