WindowsAzure.Storage v2 StorageException

Question

Ich migriere von WindowsAzure.StorageClient 1.7 zu WindowsAzure.Storage 2.0, und ich arbeite gerade an der Verwaltung der Ausnahmen. Im Anschluss an diesen guide und anderen Quellen, fand ich heraus, dass ich aus

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

zu

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

Sieht einfach zu migrieren hatte. Das Problem ist ExtendedErrorInformation ist immer gleich null. Die HttpStatusMessage sagt stattdessen "Das angegebene Blob existiert nicht.", Wie es sollte.

Ich dachte, es wurde durch den Simulator der Testumgebung verursacht, aber es in einer echten Azure-Umgebung zu versuchen, trieb mich in die gleiche Situation.

Irgendeine Idee?

Answer 1

Ich habe es gerade versucht und war überrascht zu sehen, dass in der Tat das ExtendedErrorInformation-Objekt null ist. Es ist jedoch nicht immer null. Wenn ich beispielsweise versuche, einen Blob-Container zu erstellen, der bereits mit der Methode blobContainer.Create() existiert, erhalte ich eine Nicht-Null-ExtendedErrorInformation. Wenn ich jedoch versuche, Attribute eines Blobs abzurufen, die nicht im Blob-Container vorhanden sind, erhalte ich ein Null-ExtendedErrorInformation-Objekt. Ich denke, man kann nicht einfach davon ausgehen, dass das ExtendedErrorInformation-Objekt immer verfügbar sein wird.

Auch ich habe festgestellt, dass Sie in Ihrem Code für 2.0, StorageErrorCodeStrings verwenden. Bitte beachten Sie, dass es von 2.0 entfernt ist und nur mit der Version 1.8 oder früher verfügbar ist. Dachte ich sollte erwähnen, dass

Update: Bitte beachten Sie den Kommentar unten von @VollmonD. Dies wurde in der Version 2.0.3 hinzugefügt.

Answer 2

Eine andere Möglichkeit ist stattdessen die RequestInformation.HttpStatusCode anzusehen. Dies scheint sowieso zuverlässiger zu sein. Ihr Code übersetzt und nicht leicht zu:

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

Answer 3

spät zur Party, aber wenn Sie Löschen von Elementen aus dem Blob zu behandeln versuchen oder einfach nur überprüft, ob sie existieren (Extension-Methode irgendwie nähern). Sie können nun:

• CloudBlob.DeleteIfExistsAsync() - https://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storage.blob.cloudblockblob.deleteifexistsasync.aspx

• CloudBlob.ExistsAsync() - https://msdn.microsoft.com/en-us/library/mt423366.aspx

Hier finden Sie eine Liste der Methoden auf CloudBlob: https://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storage.blob.cloudblockblob.aspx