Wie behandelt man WinRT-Exceptions, die zu Exception führen?

Question

Wenn ein Windows-Laufzeittyp einen COM-Fehler auslöst, scheint .NET diesen Fehler oft (oder immer?) Nur in eine Exception-Instanz einzubetten. Die Fehlermeldung enthält den COM HRESULT-Fehlercode. Bei Verwendung der neuen Cryptographic API mit AES-CBC zum Beispiel führt eine falsche Pufferlänge zu einem Exception mit der Meldung "Der angegebene Benutzerpuffer ist für die angeforderte Operation nicht gültig. (Exception from HRESULT: 0x800706F8)".

Nun, wie sollen wir mit diesen Ausnahmen umgehen? Sollten wir den HRESULT Code von der Ausnahme lesen, um eine Idee zu bekommen, welche Art von Ausnahme das war? In klassischen .NET würde ich eine CryptographicException bekommen, die ich verwenden könnte, um kryptografische Fehler von anderen Fehlern zu unterscheiden.

Eine andere Sache, die ich nicht verstehe, ist, dass die Microsoft-Codequalitätsregeln angeben, dass man niemals Exception sondern immer abgeleitete Typen werfen sollte. Der Grund ist, dass niemand gezwungen sein sollte, den allgemeinen Exception zu fangen, der auch mehr fatale Ausnahmen wie OutOfMemoryException fängt. Eine andere Regel besagt, dass man niemals Exceptio n in Bibliotheken fangen sollte. Wie können wir diesen Richtlinien folgen, wenn wir gezwungen sind, Exception in Windows Store-Apps oder WinRT-Bibliotheken zu erfassen?

Übrigens: Clemens Vasters shows in his blog how we can catch Exception while avoiding to catch fatal exception. Ich nehme an, Exception ist nicht mehr schlechter Code dann.

Answer 1

Es ist möglich, Exception abzufangen, bestimmte Fehler zu behandeln, indem das HRESULT eingeschaltet wird, und Exception erneut zu werfen, wenn der Fehler "unerwartet" war. Zum Beispiel

try 
{ 
    // ... 
} 
catch (Exception ex) 
{ 
    switch (ex->HResult) 
    { 
    case E_INVALID_USER_BUFFER: // 0x800706f8 
     // handle invalid buffer case... 
     break; 
    default: 
     // Unexpected exception; re-throw: 
     throw; 
    } 
} 

(Ich möchte darauf hinweisen, dass ein ungültigen Puffer klingt eher wie ein logischen Fehler als ein Laufzeitfehler, so frage ich mich, ob diese besondere Ausnahme wirklich gefangen werden soll.)

Alternativ kann einen Eine allgemeinere Lösung wäre, eine Funktion oder einen Satz von Funktionen zu schreiben, die Exception für bekannte HRESULTs behandeln und eine spezifischere Ausnahme erneut auslösen. Zum Beispiel

static void HandleKnownExceptions(Action f) 
{ 
    try 
    { 
     f(); 
    } 
    catch (Exception ex) 
    { 
     // Detect expected HRESULTs and throw the more-specific exception 
     // type for each. 
    } 
} 

Beide Ansätze funktionieren gleichermaßen in C++ und C#.

Beachten Sie, dass es nicht unbedingt der Fall ist, dass Exception direkt von der Plattform oder anderen Komponenten geworfen wird. Auf der ABI-Schicht von Windows Runtime gibt es keine Ausnahmen: Alle Fehler werden über die ABI-Grenze von HRESULT gemeldet. Die CLR übersetzt eine Handvoll bekannter HRESULT in spezifischere Ausnahmetypen, kann jedoch keine allgemeine Übersetzung durchführen.