Exception.HResult: Int oder UInt?



  • Hallo Forum,

    eine Anwendung wirft Exceptions die sich nur im HResult unterscheiden. Ich mache also eine Auswertung im Catch Block. Nehmen wir an das VS ist gerade im Hexadecimal Modus (zb im Überwachungsfenster einen Rechtsklick machen und auswählen.) Wie kann man die Exception ermitteln:

    try {
        // Die Zahl -2146233087 ist in Hexadecimalschreibweise: 0x80131501
        throw new System.Runtime.InteropServices.ExternalException("ss", -2146233087);
    } catch (Exception ex) {
        switch (ex.HResult) {
            case 0x80131501: // <- Uint, soll aber Int sein.
                // Do Something!
                break;
    		default:
                break;
    	}
    }
    

    Also das Problem ist das das Visual Studion scheinbar keine negativen Hexadecimalzahlen anzeigt, sie werden als positive Zahlen angezeigt. Erst im Kontext des Datentyps ist ersichtlich ob es sich um eine große positive oder betragsmäßig kleinere negative Zahl handelt. Um das Problem auf den Punkt zu bringen: Wie weise ich einer Int Variablen eine große negative Zahl in Hex Schreibweise zu?

    Bei Int gibt es scheinbar keinen passenden Suffix:
    http://www.dotnetperls.com/suffix

    Ich könnte jetzt alles auf Decimal umstellen, aber das wäre die Feigling Lösung!

    Peter



  • Ein HRESULT ist nicht positiv oder negativ, das ist die severity Bits, die gesetzt oder nicht gesetzt sind. Ein Hresult wird üblicherweise in Hex Schreibweise angegeben, da spielen Vorzeichen eh keine Rolle.



  • Mit welchen Änderungen würdest du dann obigen Source kompilieren?



  • Explizit nach int casten:

    case (int)0x80131501:
    


  • Also so:

    case unchecked((int)0x80131501):
    

    Das man den negtiven Hex-Zahlen kein bleibendes Minus Zeichen mitgeben kann ist schon komisch.



  • Hex Zahlen brauchen kein Minus. Hex ist eine bequeme Darstellung der Bytes, weil die Hexdarstellung immer gleich breit ist. Ob das eine negative Zahl sein soll oder nicht, ist völlig egal. In dem most significant byte steht halt 0x80. Das hat einen gewissen Informationsgehalt. -5 oder was auch immer da rauskommen würde, wenn man das erste Bit als Minuszeichen interpretiert hätte viel weniger Informationsgehalt.



  • @abcd
    Ja genau, sorry, unchecked vergessen.

    @Mechanics
    Verstehe ich nicht, wieso sollte "Minus brauchen oder nicht brauchen" bei Hex anders sein als bei Dezimal?

    In diesem speziellen Fall würde es natürlich keinen Sinn machen den HRESULT Code als negative Zahl zu schreiben. Weil der Code eben 0x80131501 ist, und mit dem findet man die gesuchten Informationen viel besser als mit -irgendwas .

    Generell ist das aber nicht unbedingt so.



  • Das mit den negativen Vorzeichen bei HEx Zahlen geht jetzt doch. Entweder habe ich gestern mit anderen Einstellungen gearbeitet, oder Tomaten auf den Augen gehabt:

    try {
        // Die Zahl -2146233087 ist in Hexadecimalschreibweise: 0x80131501
        throw new System.Runtime.InteropServices.ExternalException("ss" , -2146233087);
    } catch (Exception ex) {
        switch (ex.HResult) {
            case -0x7FECEAFF: // 0x7FECEAFF == 2146233087
    
                if (-0x7FECEAFF == 0x80131501) 
                    break;
    
                if ((int)-0x7FECEAFF == unchecked((int)0x80131501))
                    break;
        }
    }
    


  • Hätte mir auch gedacht dass das gehen muss.
    Macht nur in diesem Fall keinen Sinn, weil man eben mit -0x7FECEAFF nix findet, mit 0x80131501 aber sehrwohl.


Anmelden zum Antworten