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をテストすることを考えていましたが、メッセージは時間の経過とともに変化する可能性があるため、テストするのはそれほど安全ではないと感じています。元のロジックの動作を維持したい場合、この場合はどうすればよいですか？

4

1 に答える 1

1

古いライブラリのErrorCodeは、実際には新しいライブラリのErrorCodeとは異なります。古いライブラリは、例外タイプ、HTTPステータスコード、およびサーバーから返されたエラーコード（存在する場合）に基づいてエラーを分類しようとしました。場合によっては、さまざまなエラーがStorageErrorCodeの単一の値にマップされたため、これにより混乱が生じていました。

したがって、Azure Storage Client Library 2.0では、従来のStorageErrorCode列挙型は存在しなくなりました。代わりに、HTTPステータスコードを直接確認するようユーザーに依頼します。サーバーが応答本文を返す場合は、ステータスとエラーコードの記事でも説明されているように、詳細情報を含めることができます。このデータが存在する場合、それに応じてErrorCodeが入力されます。

この例では、FetchAttributesはGet Blob Propertiesリクエストを発行しますが、これはレスポンスの本文を返しません。これが、 ExtendedErrorInformationがnullであった理由です。

于 2013-03-26T23:59:52.043 に答える