Ausnahmen. Kapitel 19

Transkript

1 Kapitel 19 Ausnahmen Die Evolution der Ausnahmebehandlung Die Funktionsweise der Ausnahmebehandlung CLS-kompatible und nicht CLS-kompatible Ausnahmen Was genau ist eine Ausnahme? Die Klasse System.Exception Ausnahmeklassen in der FCL Auslösen einer Ausnahme Definieren einer eigenen Ausnahmeklasse Wie Sie Ausnahmen richtig einsetzen Leistungsaspekte Unbehandelte Ausnahmen Stackabbilder nach Ausnahmen Ausnahmen debuggen In diesem Kapitel werde ich Ihnen einen leistungsfähigen Mechanismus vorstellen, der Ihnen hilft, besser wartbaren und robusteren Code zu schreiben: die Ausnahmebehandlung (exception handling). Die wichtigsten Vorteile der Ausnahmebehandlung sind: Sie können Bereinigungscode an einer Stelle zusammenfassen und sicher sein, dass dieser Bereinigungscode ausgeführt wird: Wenn Sie den Bereinigungscode (cleanup code) aus den Hauptcodepfaden einer Anwendung herauslösen und an einer genau definierten Stelle zusammenfassen, ist die Anwendung einfacher zu schreiben, zu verstehen und zu pflegen. Weil Sie sicher sein können, dass der Bereinigungscode ausgeführt wird, läuft die Anwendung zuverlässiger und in einem konsistenten Zustand. Zum Beispiel werden Dateien geschlossen, falls der Codeabschnitt, der in die Datei schreibt, seine Arbeit nicht fortsetzen kann, weil eine Ausnahme im Programm ausgelöst wird. Sie können Code, der ungewöhnliche Situationen verarbeitet, an einer zentralen Stelle zusammenfassen: Eine Codezeile kann aus vielerlei Gründen fehlschlagen. Einige Beispiele: arithmetischer Überlauf, Stacküberlauf, Speichermangel, ungültige Argumente, ein ungültiger Arrayindex oder der Zugriff auf eine Ressource (etwa beim Dateizugriff), nachdem sie freigegeben wurde. Ohne Ausnahmebehandlung ist es sehr schwierig wenn nicht gar unmöglich, Code zu entwickeln, der solche Fehler abfängt und in genau definiertem Zustand mit der Verarbeitung fortfährt. Wenn Sie den Code zum Abfangen dieser potentiellen Probleme in die Hauptlogikpfade Ihrer Anwendung verteilen, ist der Code schwierig zu schreiben, zu verstehen und zu pflegen. Und in den meis-

2 434 Kapitel 19: Ausnahmen ten Fällen verschlechtert sich die Leistung einer Anwendung deutlich, wenn Code hinzugefügt wird, um diese potentiellen Fehlerursachen zu überprüfen. Wenn Sie die Ausnahmebehandlung nutzen, brauchen Sie keinen Code zu schreiben, der diese potentiellen Probleme entdeckt. Sie schreiben Ihren Code einfach so, als würden keine Fehler auftreten. So ist der Code einfacher zu schreiben, zu verstehen und zu pflegen. Und der Code läuft schneller als Code, der mit Überprüfungen auf außergewöhnliche Bedingungen durchsetzt ist. Nachdem Sie Ihren Codeblock geschrieben haben, fassen Sie den gesamten Bereinigungscode an einer zentralen Stelle zusammen. Der Ausnahmebehandlungsmechanismus wird nur aktiv, wenn ein Fehler auftritt. In diesem Fall führt er Ihren Bereinigungscode aus. Sie können Bugs im Code entdecken und korrigieren: Ist ein Fehler aufgetreten, untersucht die Common Language Runtime (CLR) den Aufrufstack des Threads und sucht nach Code, der die Ausnahme behandeln kann. Findet die CLR keinen geeigneten Code, meldet sie eine unbehandelte Ausnahme. Sie können die Stelle im Quellcode, die diesen Fehler ausgelöst hat, einfach lokalisieren und korrigieren. Sie werden also Bugs während der Entwicklungs- und der Testphase einer Anwendung zuverlässiger aufspüren und korrigieren können, bevor die Anwendung ausgeliefert wird. Ist die Anwendung beim Kunden installiert, wird sie robuster sein und die Zufriedenheit der Benutzer erhöhen. Wenn die Ausnahmebehandlung richtig eingesetzt wird, ist sie ein großartiges Werkzeug, das dem Softwareentwickler seine Aufgabe deutlich erleichtert. Die Ausnahmebehandlung kann aber auch Auslöser für eine Menge Frust sein, falls Sie nicht korrekt damit umgehen: Sie kann schwere Probleme verbergen oder Ihnen falsche Informationen liefern, statt Sie auf die eigentliche Ursache hinzuweisen. Dieses Kapitel soll Ihnen zeigen, wie Sie die Ausnahmebehandlung richtig einsetzen. Die Evolution der Ausnahmebehandlung Als Microsoft die Win32-API und COM entwickelte, entschieden sich die Entwicklerteams, den Code, der Win32-Funktionen aufruft, nicht mithilfe von Ausnahmen über Probleme zu informieren. Stattdessen liefern die meisten Win32-Funktionen ein BOOL-Ergebnis mit dem Wert FALSE, wenn etwas schief gegangen ist. Der Aufrufer kann dann mithilfe von GetLastError Informationen über die Ursache abrufen. COM-Methoden geben dagegen ein HRESULT zurück, bei dem das oberste Bit auf 1 gesetzt ist, wenn ein Fehler auftrat. Die übrigen Bits liefern dann Informationen über die Ursache des Problems. Es gab mehrere Gründe, warum Microsoft in den Win32- und COM-APIs Ausnahmen vermeiden wollte: Die meisten Entwickler waren nicht mit der Ausnahmebehandlung vertraut. Viele Programmiersprachen, darunter C und frühe Versionen von C++, unterstützten keine Ausnahmen. Manche Entwickler sind der Meinung, dass Ausnahmen schwierig zu verstehen und zu benutzen sind. Microsoft wollte diese Programmierer nicht abschrecken. (Persönlich bin ich der Meinung, dass die Vorteile der Ausnahmen den Lernaufwand mehr als wettmachen.) Ausnahmebehandlung kann die Geschwindigkeit einer Anwendung verringern. In bestimmten Situationen ist Ausnahmebehandlung langsamer als die Rückgabe eines Fehlercodes. Wenn Ausnahmen nur selten ausgelöst werden, können Sie diesen Faktor vernachlässigen. Auch bei diesem

3 Die Evolution der Ausnahmebehandlung 435 Punkt bin ich der Meinung, dass die Vorteile der Ausnahmebehandlung die gelegentlich auftretenden Geschwindigkeitseinbußen wettmachen. Ich denke außerdem, dass die Leistung einer Anwendung sogar steigen kann, wenn der Entwickler die Ausnahmebehandlung korrekt einsetzt. Auf Geschwindigkeitsfragen werde ich weiter unten in diesem Kapitel noch eingehen. In verwaltetem Code sind Ausnahmen ohnehin weit weniger kostspielig als in nicht verwalteten Sprachen wie C++. Die alten Methoden, Fehler zu melden, waren zu beschränkt, weil der Aufrufer lediglich eine 32 Bit breite Zahl zurückerhält. Steht der Fehlercode für ein ungültiges Argument, weiß der Aufrufer nicht, um welches Argument es sich handelt. Und wenn der Fehlercode für eine Division durch null gemeldet wird, weiß der Aufrufer nicht genau, in welcher Codezeile dieser Fehler auftrat. Daher kann der Entwickler den Fehler auch nicht so einfach beseitigen. Die Softwareentwicklung ist schon schwierig genug, da wollen Sie nicht auch noch, dass wichtige Details über Fehlerursachen verloren gehen. Falls der Anwendungscode ein Problem entdeckt, wollen Sie alle verfügbaren Informationen über die Ursache bekommen, damit Sie den Fehler so schnell und so einfach wie möglich korrigieren können. Der Mechanismus der Ausnahmebehandlung bietet gegenüber einem 32-Bit-Fehlercode eine Reihe von Vorteilen. Eine Ausnahme enthält eine Beschreibung des Fehlers in Form eines Strings. Falls zum Beispiel eine Ausnahme wegen eines ungültigen Arguments ausgelöst wird, wissen Sie genau, welches Argument das Problem verursacht hat. Der String kann auch zusätzliche Informationen enthalten, die Ihnen beim Korrigieren Ihres Codes helfen. Und eine Ausnahme enthält ein Stackabbild (stack trace). So können Sie herausfinden, welchen Codepfad die Anwendung genommen hat, als die Ausnahme ausgelöst wurde. Ein weiterer Vorteil ist, dass Ausnahmen nicht an der Stelle abgefangen oder entdeckt werden müssen, an der sie auftreten. Beliebiger Code im Aufrufstack des Threads kann eine ausgelöste Ausnahme behandeln. Dadurch wird die Programmentwicklung deutlich einfacher, weil Sie nicht alle Anweisungen und Methodenaufrufe, die schief gehen könnten, einzeln mit Prüf- und Fehlerbehandlungscode umgeben müssen. Der wahrscheinlich größte Vorteil der Ausnahmebehandlung hängt eng mit dem letzten Punkt zusammen: Sie können eine Ausnahme nicht so einfach ignorieren. Falls eine aufgerufene Win32- Funktion einen Fehlercode zurückliefert, ist es für den Aufrufer lachhaft einfach, den Ergebniswert zu ignorieren und anzunehmen, dass die Funktion ihre Aufgabe wie vorgesehen ausgeführt hat. Die Anwendung läuft dann weiter, als wäre nichts geschehen. Löst dagegen eine Methode in verwaltetem Code eine Ausnahme aus, macht sie unmissverständlich klar, dass sie ihre Aufgabe nicht wie gewünscht erledigen konnte. Fängt die Anwendung die Ausnahme nicht ab, beendet die CLR die Anwendung. Manchen Entwicklern kommt dieses Verhalten übertrieben streng vor. Ich denke aber, es ist das richtige, weil die Anwendung nicht einfach weiterlaufen darf, falls beim Aufrufen einer Methode eine Ausnahme ausgelöst wird. Die anderen Teile der Anwendung nehmen an, dass die letzte Operation wie erwartet abgeschlossen wurde. Ist das nicht der Fall, wird die Anwendung zwar weiterlaufen, die Ergebnisse sind aber nicht vorherzusagen. Wenn zum Beispiel die Daten des Benutzers innerhalb der Anwendung beschädigt wurden, dürfen diese Daten nicht weiter verarbeitet werden. Bei den Rückgabewerten von Win32 und COM war die Wahrscheinlichkeit, dass die Anwendung einfach weiterlief und seltsame Ergebnisse produzierte, viel zu hoch. Mit Ausnahmen kann das nicht passieren. Alle Methoden, die von Typen des Microsoft.NET Frameworks definiert werden, lösen Ausnahmen aus, falls die Methode ihre Operationen nicht abschließen konnte. Die Methoden geben keine 32-Bit-

4 436 Kapitel 19: Ausnahmen Fehlercodes zurück. Daher muss jeder Programmierer die Ausnahmebehandlung verstehen und wissen, wie er in seinem Code damit umgeht. Microsoft hat sich hier zu einem klaren Schnitt entschlossen. Sie können die Ausnahmebehandlung auf einfache Weise in Ihren Code integrieren. Diese Technik ermöglicht Ihnen, Code zu schreiben, der einfach zu implementieren, zu lesen und zu pflegen ist. Außerdem hilft Ihnen die Ausnahmebehandlung, robusten Code zu entwickeln, der mit jeder Situation fertig wird. Wenn Sie die Ausnahmebehandlung korrekt einsetzen, vermeiden Sie Anwendungsabstürze und Ihre Benutzer sind zufrieden. Die Funktionsweise der Ausnahmebehandlung In diesem Abschnitt werde ich die Funktionsweise der Ausnahmebehandlung erläutern und Ihnen die C#-Konstrukte vorstellen, die Sie brauchen, um die Ausnahmebehandlung zu nutzen. Dabei möchte ich aber nicht zu sehr ins Detail gehen. Dieses Kapitel soll Ihnen in erster Linie Richtlinien anbieten, wann und wie Sie die Ausnahmebehandlung in Ihrem Code nutzen. Wenn Sie weitere Informationen über die Funktionsweise und die Sprachkonstrukte der Ausnahmebehandlung suchen, finden Sie in der Dokumentation des.net Frameworks und in der C#-Sprachspezifikation ausführliches Material. Die Ausnahmebehandlung des.net Frameworks basiert technisch auf der strukturierten Ausnahmebehandlung (Structured Exception Handling, SEH) von Microsoft Windows. SEH wird in vielen Texten erläutert, zum Beispiel in meinem Buch Microsoft Windows Programmierung für Experten (4. Auflage, Microsoft Press, 2000); drei Kapitel in diesem Buch sind dem Thema SEH gewidmet. Der folgende C#-Code zeigt einen normalen Anwendungsfall für die Ausnahmebehandlung. Der Programmausschnitt vermittelt Ihnen einen Eindruck, wie Ausnahmebehandlungsblöcke aussehen und welchen Zweck sie haben. In den Unterabschnitten im Anschluss an das Listing werde ich die try-, catch- und finally-blöcke beschreiben und erläutern, wie Sie diese Konstrukte einsetzen. private void SomeMethod() { try { // In den try-block kommt der Code, für den Sie Fehler abfangen // wollen oder nach dessen Ausführung Sie Bereinigungscode benötigen. catch (InvalidOperationException) { // In diesen catch-block kommt der Code, der die Ausnahme // InvalidOperationException behandelt (oder irgendeinen // Ausnahmetyp, der von InvalidOperationException abgeleitet ist). catch (IOException) { // In diesen catch-block kommt der Code, der die Ausnahme // IOException behandelt (oder irgendeinen Ausnahmetyp, // der von IOException abgeleitet ist). catch { // In diesen catch-block kommt der Code, der eine beliebige // Ausnahme behandelt. // Wenn Sie eine beliebige Ausnahme abgefangen haben, // lösen Sie die Ausnahme normalerweise erneut aus. Diesen // Vorgang erkläre ich weiter unten in diesem Kapitel. throw;

5 Die Funktionsweise der Ausnahmebehandlung 437 finally { // In den finally-block kommt der Code, mit dem Sie nach // allen Operationen aufräumen, die im try-block begonnen // wurden. Der Code in diesem Block wird IMMER ausgeführt, // egal ob eine Ausnahme ausgelöst wurde oder nicht. // Der Code nach dem finally-block wird ausgeführt, falls innerhalb // des try-blocks keine Ausnahme ausgelöst wurde oder falls ein // catch-block die Ausnahme abgefangen, aber keine Ausnahme erneut // ausgelöst hat. Dieser Codeausschnitt zeigt eine Möglichkeit, wie Sie Anweisungsblöcke für die Ausnahmebehandlung schreiben können. Lassen Sie sich von diesem Code nicht einschüchtern: In den meisten Methoden werden Sie lediglich einen try-block in Kombination mit einem einzigen finally-block benötigen oder einen try-block mit einem einzigen catch-block. Mehrere catch-blöcke wie in diesem Beispiel sind ungewöhnlich, ich habe sie hier nur versammelt, damit Sie alle Anweisungsblöcke der Ausnahmebehandlung kennen lernen. Der try-block Ein try-block enthält Programmcode, der Bereinigungscode und/oder eine Ausnahmebehandlung benötigt. Den Bereinigungscode sollten Sie in einem einzigen finally-block zusammenfassen. Ein try-block kann auch Code enthalten, der möglicherweise eine Ausnahme auslöst. Den Code zum Abfangen der Ausnahme schreiben Sie in einen oder mehrere catch-blöcke. Für jede Ausnahme, die Ihre Anwendung verarbeiten kann, erstellen Sie einen catch-block. Auf einen try-block muss mindestens ein catch- oder finally-block folgen, ein isolierter try-block erfüllt keinen Sinn. Daher verbietet C# auch ein solches Konstrukt. Der catch-block Ein catch-block enthält Code, der ausgeführt wird, falls eine Ausnahme aufgetreten ist. Mit einem try-block können beliebig viele catch-blöcke verknüpft sein. Falls der Code im try-block keine Ausnahme auslöst, führt die CLR keinen Code aus irgendwelchen catch-blöcken aus. Der Thread überspringt sämtliche catch-blöcke und führt den Code im finally-block aus (falls einer vorhanden ist). Nachdem der Code des finally-blocks abgearbeitet ist, wird mit der Verarbeitung der Anweisung weitergemacht, die unmittelbar auf den finally-block folgt. Der Klammerausdruck nach dem Schlüsselwort catch wird als der catch-typ bezeichnet. In C# müssen Sie als catch-typ den Typ System.Exception angeben oder einen Typ, der von System.Exception abgeleitet ist. Zum Beispiel enthält der Code aus dem letzten Beispiel catch-blöcke zum Behandeln einer InvalidOperationException (oder einer Ausnahme, die davon abgeleitet ist) und einer IOException (oder einer Ausnahme, die davon abgeleitet ist). Der letzte catch-block (der keinen catch-typ angibt) behandelt alle Ausnahmen. Das ist dasselbe, als hätten Sie einen catch-block mit dem catch- Typ System.Exception, allerdings können Sie im Code innerhalb des catch-blocks ohne catch-typ nicht auf die Informationen der Ausnahme zugreifen.

6 438 Kapitel 19: Ausnahmen HINWEIS Wenn Sie im Microsoft Visual Studio mit dem Debugger durch einen catch-block gehen, können Sie das momentan ausgelöste Ausnahmeobjekt sehen, indem Sie die spezielle Variable»$exception«in das Fenster Überwachen einfügen. Die CLR sucht von oben nach unten nach einem passenden catch-typ. Daher müssen Sie die spezifischeren Ausnahmetypen weiter nach vorne setzen. Die Ausnahmetypen, die in der Ableitungshierarchie am weitesten von der Wurzel entfernt sind, sollten zuerst kommen, gefolgt von ihren Basistypen (sofern vorhanden), bis hinunter zu System.Exception (oder einem Ausnahmeblock, der keinen catch-typ angibt). Der C#-Compiler meldet sogar einen Fehler, falls ein spezifischerer catch- Block zu weit unten steht, weil dieser catch-block dann nie ausgeführt werden könnte. Falls der Code im try-block (oder eine Methode, die dieser Code aufruft) eine Ausnahme auslöst, sucht die CLR nach catch-blöcken, deren catch-typ der ausgelösten Ausnahme entspricht. Falls die CLR keinen geeigneten catch-typ findet, sucht sie im Aufrufstack nach einem catch-typ, der der Ausnahme entspricht. Falls die CLR den Stack bis zur Spitze durchlaufen hat, ohne einen catch-block mit einem passenden catch-typ zu finden, meldet sie eine unbehandelte Ausnahme. Weiter unten in diesem Kapitel werde ich unbehandelte Ausnahmen eingehender erläutern. Findet die CLR einen catch-block mit einem passenden catch-typ, führt sie den Code in allen inneren finally-blöcken aus. Dabei beginnt sie im try-block, dessen Code die Ausnahme ausgelöst hat, und geht bis zu dem catch-block, der die Ausnahme behandelt. Der finally-block in dem Konstrukt, dessen catch-filter die Ausnahme behandelt, wird vorerst noch nicht ausgeführt. Er läuft erst, nachdem der catch-block ausgeführt wurde. Nachdem der gesamte Code in allen inneren finally-blöcken ausgeführt wurde, läuft der Code in dem catch-block, der die Ausnahme behandelt. Dieser Code führt normalerweise einige Operationen aus, um einen konsistenten Zustand wiederherzustellen. Am Ende des catch-blocks haben Sie drei Möglichkeiten: Sie können dieselbe Ausnahme erneut auslösen (rethrow). Auf diese Weise informieren Sie Codeteile weiter oben im Aufrufstack über die Ausnahme. Sie können eine andere Ausnahme auslösen. Auf diese Weise können Sie den Codeteilen weiter oben im Aufrufstack detailliertere Informationen über die Ausnahme übermitteln. Sie können die Ausführung hinter dem catch-block fortsetzen. Weiter unten in diesem Kapitel werde ich Ihnen einige Richtlinien vorstellen, die Sie zu Rate ziehen können, wenn Sie sich für eine dieser drei Möglichkeiten entscheiden müssen. Falls Sie eine der ersten beiden Techniken wählen, lösen Sie wiederum eine Ausnahme aus. Die CLR verhält sich dann wie zuvor: Sie durchsucht den Aufrufstack nach einem catch-block, dessen catch- Typ dem Typ der ausgelösten Ausnahme entspricht. Entscheiden Sie sich für die dritte Technik, wird unmittelbar nach dem Code im catch-block der Code im finally-block ausgeführt (falls einer vorhanden ist). Nachdem der Code im finally-block abgearbeitet ist, setzt der Thread die Ausführung mit den Befehlen unmittelbar hinter dem finally- Block fort. Gibt es keinen finally-block, setzt der Thread die Ausführung mit den Befehlen unmittelbar nach dem letzten catch-block fort. In C# können Sie nach einem catch-typ einen Variablennamen angeben. Wird eine Ausnahme abgefangen, verweist diese Variable auf das von System.Exception abgeleitete Objekt, das als Ausnahme

7 Die Funktionsweise der Ausnahmebehandlung 439 ausgelöst wurde. Der Code im catch-block kann auf diese Variable zugreifen, um Informationen über die Ausnahme abzurufen (zum Beispiel das Stackabbild zum Zeitpunkt, als die Ausnahme auftrat). Es ist zwar möglich, dieses Objekt zu verändern, Sie sollten es aber als schreibgeschützt betrachten. Weiter unten in diesem Kapitel werde ich den Typ Exception genauer erklären und beschreiben, was Sie damit tun können. Der finally-block Ein finally-block enthält Code, der garantiert ausgeführt wird. Normalerweise ist dies Bereinigungscode, der nach den Aktionen im try-block aufräumt. Wenn Sie zum Beispiel in einem try- Block eine Datei öffnen, stellen Sie den Code zum Schließen der Datei in einen finally-block: private void ReadData(String pathname) { FileStream fs = null; try { fs = new FileStream(pathname, FileMode.Open); // Die Daten der Datei verarbeiten.... catch (IOException) { // In diesen catch-block schreiben Sie den Code, der eine IOException // behandelt (oder einen Ausnahmetyp, der von IOException abgeleitet ist).... finally { // Sicherstellen, dass die Datei geschlossen wird. if (fs!= null) fs.close(); Läuft der Code im try-block ab, ohne dass eine Ausnahme ausgelöst wird, wird die Datei garantiert geschlossen. Tritt im try-block eine Ausnahme auf, wird der Code im finally-block trotzdem ausgeführt und die Datei wird garantiert geschlossen. Dabei ist egal, ob die Ausnahme abgefangen wird oder nicht. Sie dürfen die Anweisung zum Schließen der Datei keinesfalls hinter den finally-block schreiben: In diesem Fall würde die Anweisung nicht ausgeführt werden, falls eine Ausnahme auftritt und abgefangen wird. Die Datei bliebe offen. Einem try-block muss nicht unbedingt ein finally-block zugeordnet sein. Manchmal ist für die Operationen in einem try-block kein Bereinigungscode notwendig. Falls Sie aber einen finally- Block haben, muss er nach dem letzten catch-block stehen. Ein try-block darf auch nicht mit mehreren finally-blöcken verknüpft sein. Wenn der Thread den Code in einem finally-block vollständig ausgeführt hat, setzt er die Verarbeitung mit der Anweisung fort, die unmittelbar auf den finally-block folgt. Die Befehle im finally- Block sind Bereinigungscode. Dieser Code sollte nur die Operationen aufräumen, die im try-block begonnen wurden. Vermeiden Sie in einem finally-block Anweisungen, die eine Ausnahme auslösen können. Passiert das doch einmal, ist es trotzdem nicht das Ende der Welt: Der Ausnahmebehandlungsmechanismus der CLR arbeitet so weiter, als wäre die Ausnahme hinter dem finally-block ausgelöst worden. Die CLR verwirft dann allerdings die erste Ausnahme, die unter Umständen im entsprechenden try-block ausgelöst wurde. Sie verlieren dadurch sämtliche Informationen (zum Beispiel das Stackabbild), die über die erste Ausnahme zur Verfügung standen.

8 440 Kapitel 19: Ausnahmen CLS-kompatible und nicht CLS-kompatible Ausnahmen Alle Programmiersprachen für die CLR müssen das Auslösen von Ausnahmeobjekten unterstützen, die von Exception abgeleitet sind, weil die Common Language Specification (CLS) das vorschreibt. Die CLR erlaubt allerdings, dass eine Instanz eines beliebigen Typs als Ausnahme ausgelöst wird, und einige Programmiersprachen erlauben Code, der nicht CLS-kompatible Ausnahmeobjekte auslöst, zum Beispiel vom Typ String, Int32 oder DateTime. Der C#-Compiler erlaubt nur das Auslösen von Ausnahmeobjekten, die von Exception abgeleitet sind. Dagegen kann Code, der in IL-Assemblersprache oder C++/CLI geschrieben ist, nicht nur von Exception abgeleitete Objekte auslösen, sondern auch Objekte, die nicht von Exception abgeleitet sind. Viele Programmierer wissen gar nicht, dass die CLR es zulässt, beliebige Objekte als Ausnahme auszulösen. Die meisten Entwickler glauben, dass nur von Exception abgeleitete Objekte benutzt werden können. Wenn Programmierer vor der Version 2.0 der CLR catch-blöcke zum Abfangen von Ausnahmen schrieben, fingen sie ausschließlich CLS-kompatible Ausnahmen ab. Falls eine C#-Methode eine Methode aufrief, die in einer anderen Sprache geschrieben war, und diese Methode eine nicht CLS-kompatible Ausnahme auslöste, fing der C#-Code diese Ausnahme überhaupt nicht ab. Das führte zu einigen Sicherheitslücken. In Version 2.0 der CLR hat Microsoft die neue Klasse RuntimeWrappedException eingeführt (definiert im Namespace System.Runtime.CompilerServices). Diese Klasse ist von Exception abgeleitet, sie ist also ein CLS-kompatibler Ausnahmetyp. Die Klasse RuntimeWrappedException enthält ein privates Feld vom Typ Object (auf das Sie über die schreibgeschützte Eigenschaft WrappedException von RuntimeWrappedException zugreifen können). Wenn in Version 2.0 der CLR eine nicht CLS-kompatible Ausnahme ausgelöst wird, legt die CLR automatisch eine Instanz der Klasse RuntimeWrappedException an und initialisiert dieses private Feld mit einem Verweis auf das Objekt, das tatsächlich ausgelöst wurde. Die CLR verwandelt also im Grund alle nicht CLS-kompatiblen Ausnahmen in CLS-kompatible Ausnahmen. Jeder Code, der jetzt einen Exception-Typ abfängt, fängt auch Ausnahmen ab, die nicht CLS-kompatibel sind. Damit sind die potentiellen Sicherheitslücken geschlossen. Der C#-Compiler erlaubt den Entwicklern zwar, ausschließlich von Exception abgeleitete Objekte auszulösen, aber schon vor der C#-Version 2.0 konnten Entwickler Ausnahmen abfangen, die nicht CLS-kompatibel sind. Das geht mit Code, der zum Beispiel so aussieht: private void SomeMethod() { try { // In diesem try-block steht der Code, nach dessen Ausführung ein konsistenter // Zustand wiederhergestellt oder Aufräumcode ausgeführt werden muss. catch (Exception e) { // Vor C# 2.0 fängt dieser Block nur CLS-kompatible Ausnahmen ab. // In C# 2.0 fängt dieser Block CLS-kompatible und nicht CLS-kompatible Ausnahmen ab. throw; // Abgefangene Ausnahme erneut auslösen. catch { // Dieser Block fängt in allen Versionen von C# // CLS-kompatible und nicht CLS-kompatible Ausnahmen ab. throw; // Abgefangene Ausnahme erneut auslösen.

9 Was genau ist eine Ausnahme? 441 Manche Entwickler wussten, dass die CLR sowohl CLS-kompatible als auch nicht CLS-kompatible Ausnahmen unterstützt, und diese Entwicklern haben unter Umständen zwei catch-blöcke in Ihren Code geschrieben (wie im letzten Beispiel), um beide Ausnahmearten abzufangen. Wenn der Code aus diesem Beispiel für CLR 2.0 neu kompiliert wird, wird der zweite catch-block niemals ausgeführt und der C#-Compiler weist darauf mit einer Warnung hin:»cs1058: Eine vorherige catch-klausel hat bereits alle Ausnahmen abgefangen. Alle ausgelösten Nicht-Ausnahmen werden in eine System. Runtime.CompilerServices.RuntimeWrappedException eingebunden.«entwickler haben zwei Möglichkeiten, Code aus einer älteren Version des.net Frameworks auf Version 2.0 zu portieren: Sie können den Code aus den beiden catch-blöcken in einen einzigen catch-block zusammenführen und einen der catch-blöcke löschen. Sie können der CLR mitteilen, dass der Code in Ihrer Assembly nach den alten Regeln behandelt werden soll. Das heißt, dass Sie die CLR anweisen, in Ihren catch (Exception)-Blöcken keine Instanz der neuen Klasse RuntimeWrappedException abzufangen. Stattdessen soll die CLR das nicht CLS-kompatible Ausnahmeobjekt entpacken und Ihren Code nur aufrufen, wenn Sie einen catch- Block haben, der überhaupt keinen Typ angibt. Sie teilen der CLR mit, dass Sie das alte Verhalten haben wollen, indem Sie eine Instanz von RuntimeCompatibilityAttribute auf Ihre Assembly anwenden: using System.Runtime.CompilerServices; [assembly:runtimecompatibility(wrapnonexceptionthrows = false)] HINWEIS Dieses Attribut wirkt sich auf die gesamte Assembly aus. Es gibt keine Möglichkeit, neue und alte Ausnahmebehandlungsstile in einer einzigen Assembly zu vermischen. Passen Sie auf, wenn Sie neuen Code (der erwartet, dass die CLR Wrapper um alle Ausnahmen bildet) zu einer Assembly mit altem Code hinzufügen (bei dem die CLR keine Wrapper für Ausnahmen bildet). Was genau ist eine Ausnahme? Im Lauf der Jahre hatte ich mit vielen Entwicklern zu tun, die glauben, eine Ausnahme sei ein Ereignis, das nur selten eintritt:»ein außergewöhnliches Ereignis«. Ich frage dann immer, wie sie ein»außergewöhnliches Ereignis«definieren würden. Die Antwort:»Na ja, eben etwas, mit dem man nicht rechnet.«dann ergänzen sie:»wenn Sie Bytes aus einer Datei lesen, kommen Sie früher oder später an das Ende der Datei. Da Sie damit rechnen, sollte keine Ausnahme ausgelöst werden. Stattdessen sollte die Read-Methode einen speziellen Ergebniswert zurückgeben, der den Aufrufer informiert, dass das Dateiende erreicht ist.«meine Antwort:»Ich habe eine Anwendung, die eine 20 Byte lange Datenstruktur aus einer Datei liest. Aus irgendwelchen Gründen enthält die Datei aber nur 10 Bytes. In diesem Fall erwarte ich beim Auslesen der Datei nicht, dass das Dateiende erreicht ist. Weil ich das Dateiende zu früh erreiche, rechne ich damit, dass eine Ausnahme ausgelöst wird. Würden Sie das nicht auch erwarten?«die meisten Dateien enthalten tatsächlich strukturierte Daten. Es kommt selten vor, dass eine Anwendung Daten aus einer Datei liest und sie Byte für Byte verarbeitet, bis das Ende der Datei erreicht ist. Deshalb halte ich es für sinnvoller, wenn die Read-Methode immer eine Ausnahme auslöst, falls Sie beim Lesen über das Dateiende hinaus geraten.

10 442 Kapitel 19: Ausnahmen WICHTIG Viele Entwickler lassen sich von dem Ausdruck Ausnahmebehandlung in die Irre führen. Sie denken, dass der Begriff Ausnahme etwas damit zu tun hat, wie häufig ein Ereignis eintritt. Zum Beispiel sagt sich ein Entwickler beim Schreiben einer Read-Methode zum Auslesen einer Datei:»Beim Lesen von Daten aus einer Datei stößt man irgendwann auf das Dateiende. Da dies immer passiert, entwerfe ich meine Read-Methode so, dass sie mich mit einem speziellen Rückgabewert über dieses Ereignis informiert. Dazu muss ich keine Ausnahme auslösen.«das Problem mit dieser Aussage ist, dass der Entwickler sie macht, der die Read-Methode schreibt, nicht der Entwickler, der die Read- Methode aufruft. Wenn der Entwickler die Read-Methode entwirft, kann er unmöglich alle Situationen voraussehen, in denen die Methode aufgerufen werden wird. Daher kann er auch nicht wissen, wie oft der Aufrufer der Read-Methode versuchen wird, über das Dateiende hinaus Daten zu lesen. Da die meisten Dateien strukturierte Daten enthalten, kommt es sogar selten vor, dass eine Leseoperation hinter dem Dateiende versucht wird. Ein anderes Missverständnis ist, dass eine Ausnahme ein Fehler ist. Der Begriff Fehler impliziert, dass der Programmierer etwas falsch gemacht hat. Auch hier gilt aber wieder, dass der Entwickler der Read-Methode unmöglich wissen kann, ob ein anderer Programmierer seine Methode auf falsche Weise aufgerufen hat. Nur der Programmierer, der die Methode benutzt, kann das entscheiden. Daher kann auch nur dieser Programmierer beurteilen, ob das Ergebnis des Aufrufs ein Fehler ist. Lösen Sie sich also von dem Konzept:»Ich löse hier eine Ausnahme aus, um einen Fehler zu melden.«weil Ausnahmen nicht unbedingt über Fehler informieren, habe ich in diesem Kapitel auch bewusst auf den Begriff Fehlerbehandlung (error handling) verzichtet (außer in diesem Satz natürlich). Die letzte Anmerkung erklärt, was Ausnahme nicht bedeutet. Jetzt möchte ich Ihnen beschreiben, was der Begriff bedeutet. Wenn Sie einen Typ entwerfen, arbeiten Sie erst die verschiedenen Situationen aus, in denen Ihr Typ vermutlich benutzt wird. Der Typname ist normalerweise ein Substantiv, zum Beispiel FileStream oder StringBuilder. Dann definieren Sie die Eigenschaften, Methoden, Ereignisse und anderen Member dieser Art für den Typ. Die Art, wie Sie diese Member definieren (Datentypen von Eigenschaften, Parameter von Methoden, Rückgabewerte und so weiter), bestimmt die Programmierschnittstelle für Ihren Typ. Diese Member stehen für Operationen oder Aktionen, die vom Typ selbst oder einer Instanz des Typs ausgeführt werden können. Die Namen dieser Aktionsmember sind normalerweise Verben, zum Beispiel Read, Write, Flush, Append, Insert, Remove und so weiter. Wenn ein Aktionsmember seine Aufgabe nicht abschließen kann, sollte es eine Ausnahme auslösen. Eine Ausnahme bedeutet, dass ein Aktionsmember die Aufgabe, die es entsprechend seinem Namen ausführen sollte, nicht vollständig durchführen konnte. Sehen Sie sich die folgende Klassendefinition an: internal class Account { public static void Transfer(Account from, Account to, Decimal amount) {... Die Methode Transfer übernimmt als Parameter zwei Account-Objekte und einen Decimal-Wert, der eine Geldsumme angibt, die von einem Konto (account) auf ein anderes überwiesen werden soll. Offensichtlich besteht das Ziel der Methode Transfer darin, Geld von einem Konto abzuheben und einem anderem Konto gutzuschreiben. Es gibt viele Gründe, warum die Methode Transfer fehlschlagen könnte: Die Argumente für from oder to könnten null sein; die Argumente für from oder to könnten auf ein gesperrtes Konto verweisen; das Guthaben auf dem Konto from könnte zu gering

11 Die Klasse System.Exception 443 sein; das Guthaben auf dem Konto to könnte so hoch ein, dass beim Hinzufügen der Summe ein Überlauf eintritt; oder das Argument für amount könnte 0 sein, negativ sein oder mehr als zwei Nachkommastellen haben. Wenn die Methode Transfer aufgerufen wird, muss ihr Code alle diese Möglichkeiten prüfen. Und falls die Methode feststellt, dass eine der Bedingungen zutrifft, darf sie nicht einfach das Geld überweisen, sondern sollte den Aufrufer benachrichtigen, dass die Überweisung fehlgeschlagen ist. Dazu löst die Methode eine Ausnahme aus. Der Rückgabetyp der Methode Transfer ist sogar void. Das hat den Grund, dass die Methode Transfer keinen sinnvollen Wert zurückzugeben hat. Falls sie überhaupt zurückkehrt, war sie erfolgreich. Falls sie fehlgeschlagen ist, löst sie eine aussagekräftige Ausnahme aus. Jeder Methodenaufruf kann fehlschlagen Es gibt viele Gründe, warum beim Aufruf einer Methode eine Ausnahme ausgelöst werden kann: Falls auf dem Stack nicht mehr genug Platz ist, wird eine StackOverflowException ausgelöst. Falls die Assembly, die den Typ definiert, nicht gefunden werden kann, wird eine FileNotFound- Exception ausgelöst. Falls der IL-Code der Methode nicht überprüfbar ist, wird eine VerificationException ausgelöst. Falls nicht genug Arbeitsspeicher zur Verfügung steht, um den IL-Code mit dem JIT-Compiler zu übersetzen, wird eine OutOfMemoryException ausgelöst. Diese Liste lässt sich endlos fortsetzen. Die Lehre, die Sie aus diesem Abschnitt ziehen sollten: Jederzeit kann eine Ausnahme ausgelöst werden. Sehen Sie sich zum Beispiel die folgende Methode an: private void InfiniteLoop() { while (true) ; Die Schleife in dieser Methode könnte 1000 Mal erfolgreich durchlaufen werden, aber beim Mal wird eine Ausnahme ausgelöst. Wie könnte das passieren? Zum Beispiel könnte ein anderer Thread versuchen, diesen Thread abzubrechen, indem er die Thread-Methode Abort aufruft. Dann wird der Thread, der die Endlosschleife ausführt, angehalten und gezwungen, eine ThreadAbortException auszulösen. In CLR-Hostingszenarien wie zum Beispiel Microsoft ASP.NET und Microsoft SQL Server ist es gar nicht so ungewöhnlich, wenn Threads abgebrochen werden. Die Klasse System.Exception Die Common Language Runtime (CLR) erlaubt, dass Sie jeden beliebigen Typ zum Auslösen einer Ausnahme verwenden, vom Int32 über String bis zu beliebig komplexen Typen. Microsoft wollte aber nicht alle Programmiersprachen zwingen, Ausnahmen beliebigen Typs auszulösen und abzufangen. Daher hat Microsoft den Typ System.Exception definiert und festgelegt, dass alle CLS-kompatiblen Programmiersprachen in der Lage sein müssen, Ausnahmen auszulösen und abzufangen, deren Typ von System.Exception abgeleitet ist. Ausnahmetypen, die von System.Exception abgeleitet sind, gelten als CLS-kompatibel. Die Compiler für C# und viele andere Sprachen stellen sicher, dass Ihr Code ausschließlich CLS-kompatible Ausnahmen auslöst.

12 444 Kapitel 19: Ausnahmen Der Typ System.Exception ist äußerst simpel. Tabelle 19.1 beschreibt seine Eigenschaften. Tabelle 19.1 Öffentliche Eigenschaften des Typs System.Exception Eigenschaft Zugriff Typ Beschreibung Message Schreibgeschützt String Enthält nützliche Erklärungen über die Ursache der Ausnahme. Die Meldung wird normalerweise in ein Protokoll geschrieben, wenn eine ausgelöste Ausnahme nicht behandelt wird. Da Endbenutzer diese Meldung nicht zu Gesicht bekommen, sollte sie fachlich so detailliert wie möglich sein, damit Entwickler, die das Protokoll analysieren, anhand der Informationen aus der Meldung ihren Code korrigieren können, wenn sie eine neue Version erstellen. Data Schreibgeschützt IDictionary Ein Verweis auf eine Auflistung mit Schlüssel/Wert-Paaren. Normalerweise fügt der Code, der die Ausnahme auslöst, Einträge zu dieser Auflistung hinzu, bevor er die Ausnahme auslöst. Code, der die Ausnahme abfängt, kann die Einträge lesen und die Informationen nutzen, um einen konsistenten Zustand wiederherzustellen. Source Lesen/Schreiben String Enthält den Namen der Assembly, von der die Ausnahme ausgelöst wurde. StackTrace Schreibgeschützt String Enthält die Namen und Signaturen der Methoden, die aufgerufen wurden, bevor die Ausnahme ausgelöst wurde. Diese Eigenschaft ist beim Debuggen unverzichtbar. TargetSite Schreibgeschützt MethodBase Enthält die Methode, von der die Ausnahme ausgelöst wurde. HelpLink Schreibgeschützt String Enthält einen URL (zum Beispiel file://c:\myapp\help.htm#myexception- Help), unter dem der Benutzer in der Dokumentation mit Erläuterungen zu den Ausnahmen nachschlagen kann. Denken Sie daran, dass solide Programmier- und Sicherheitsverfahren verhindern, dass Benutzer jemals eine unbehandelte Ausnahme zu Gesicht bekommen. Falls Sie also nicht versuchen, anderen Programmierern Informationen zu liefern, wird diese Eigenschaft selten benutzt. Inner- Exception Schreibgeschützt Exception Gibt die vorherige Ausnahme an, falls die aktuelle Ausnahme ausgelöst wurde, während der Code eine andere Ausnahme behandelt hat. Diese schreibgeschützte Eigenschaft hat normalerweise den Wert null. Der Typ Exception stellt auch eine öffentliche Methode namens GetBaseException zur Verfügung, mit der Sie die verknüpfte Liste der verschachtelten Ausnahmen durchlaufen und die zuerst ausgelöste Ausnahme ermitteln können. Ausnahmeklassen in der FCL Die Framework Class Library (FCL) definiert viele Ausnahmetypen, die alle letztlich von System. Exception abgeleitet sind. Die folgende Auflistung zeigt die Hierarchie der Ausnahmetypen, die in der Assembly MSCorLib.dll definiert sind. Andere Assemblys definieren sogar noch mehr Ausnahmetypen. (Die Anwendung, mit der diese Liste erstellt wurde, finden Sie in Kapitel 22,»Laden von Assemblys und Reflektion«.) System.Exception System.ApplicationException System.Reflection.InvalidFilterCriteriaException System.Reflection.TargetException System.Reflection.TargetInvocationException System.Reflection.TargetParameterCountException System.Threading.WaitHandleCannotBeOpenedException

13 Ausnahmeklassen in der FCL 445 System.IO.IsolatedStorage.IsolatedStorageException System.Runtime.CompilerServices.RuntimeWrappedException System.SystemException System.AccessViolationException System.AppDomainUnloadedException System.ArgumentException System.ArgumentNullException System.ArgumentOutOfRangeException System.DuplicateWaitObjectException System.Text.DecoderFallbackException System.Text.EncoderFallbackException System.ArithmeticException System.DivideByZeroException System.NotFiniteNumberException System.OverflowException System.ArrayTypeMismatchException System.BadImageFormatException System.CannotUnloadAppDomainException System.Collections.Generic.KeyNotFoundException System.ContextMarshalException System.DataMisalignedException System.ExecutionEngineException System.FormatException System.Reflection.CustomAttributeFormatException System.IndexOutOfRangeException System.InvalidCastException System.InvalidOperationException System.ObjectDisposedException System.InvalidProgramException System.IO.IOException System.IO.DirectoryNotFoundException System.IO.DriveNotFoundException System.IO.EndOfStreamException System.IO.FileLoadException System.IO.FileNotFoundException System.IO.PathTooLongException System.MemberAccessException System.FieldAccessException System.MethodAccessException System.MissingMemberException System.MissingFieldException System.MissingMethodException System.MulticastNotSupportedException System.NotImplementedException System.NotSupportedException System.PlatformNotSupportedException System.NullReferenceException System.OperationCanceledException System.OutOfMemoryException System.InsufficientMemoryException System.RankException System.Reflection.AmbiguousMatchException System.Reflection.ReflectionTypeLoadException

14 446 Kapitel 19: Ausnahmen System.Resources.MissingManifestResourceException System.Resources.MissingSatelliteAssemblyException System.Runtime.InteropServices.ExternalException System.Runtime.InteropServices.COMException System.Runtime.InteropServices.SEHException System.Runtime.InteropServices.InvalidComObjectException System.Runtime.InteropServices.InvalidOleVariantTypeException System.Runtime.InteropServices.MarshalDirectiveException System.Runtime.InteropServices.SafeArrayRankMismatchException System.Runtime.InteropServices.SafeArrayTypeMismatchException System.Runtime.Remoting.RemotingException System.Runtime.Remoting.RemotingTimeoutException System.Runtime.Remoting.ServerException System.Runtime.Serialization.SerializationException System.Security.Cryptography.CryptographicException System.Security.Cryptography.CryptographicUnexpectedOperationException System.Security.HostProtectionException System.Security.Policy.PolicyException System.Security.Principal.IdentityNotMappedException System.Security.SecurityException System.Security.VerificationException System.Security.XmlSyntaxException System.StackOverflowException System.Threading.AbandonedMutexException System.Threading.SynchronizationLockException System.Threading.ThreadAbortException System.Threading.ThreadInterruptedException System.Threading.ThreadStartException System.Threading.ThreadStateException System.TimeoutException System.TypeInitializationException System.TypeLoadException System.DllNotFoundException System.EntryPointNotFoundException System.TypeUnloadedException System.UnauthorizedAccessException System.Security.AccessControl.PrivilegeNotHeldException Microsoft hatte ursprünglich die Vorstellung, dass System.Exception der Basistyp für alle Ausnahmen sein sollte. Nur zwei andere Typen sollten unmittelbar von Exception abgeleitet sein: System.System- Exception und System.ApplicationException. Ausnahmen, die von der CLR ausgelöst werden, sollten von SystemException abgeleitet sein, alle von Anwendungen ausgelösten Ausnahmen dagegen von ApplicationException. Auf diese Weise wäre es möglich, dass Entwickler einen catch-block schreiben, der alle von der CLR ausgelösten Ausnahmen abfängt, und einen anderen catch-block für alle von der Anwendung ausgelösten Ausnahmen. Wie Sie allerdings sehen, wurde diese Regel nicht sehr konsistent eingehalten: Manche Ausnahmetypen sind unmittelbar von Exception abgeleitet (zum Beispiel IsolatedStorageException), manche von der CLR ausgelöste Ausnahmen sind von ApplicationException abgeleitet (TargetInvocationException) und manche von Anwendungen ausgelöste Ausnahmen sind von SystemException abgeleitet (FormatException). Kurz gesagt: Es ist ein großes Durcheinander und das Ergebnis ist, dass die Typen SystemException und ApplicationException überhaupt keine besondere Bedeutung haben. Inzwischen

15 Definieren einer eigenen Ausnahmeklasse 447 wäre es Microsoft lieber, wenn sich diese Typen aus der Hierarchie der Ausnahmeklassen wieder entfernen ließen, aber das ist nicht möglich, weil Code, der bereits diese zwei Typen verwendet, dann nicht mehr funktionieren würde. Auslösen einer Ausnahme Wenn Sie Ihre eigenen Methoden implementieren, sollten Sie immer eine Ausnahme auslösen (throw), wenn die Methode ihre Aufgabe, die durch ihren Namen vorgegeben ist, nicht abschließen kann. Wenn Sie eine Ausnahme auslösen wollen, gibt es zwei wichtige Punkte zu bedenken: Welchen von Exception abgeleiteten Typ lösen Sie aus? Es ist wirklich wichtig, dass Sie einen Typ wählen, der für den jeweiligen Fall sinnvoll ist. Stellen Sie sich vor, auf welche Weise Code, der sich weiter oben im Aufrufstack befindet, feststellen will, dass eine Methode fehlgeschlagen ist, um dann Code zum Wiederherstellen eines konsistenten Zustands ausführen zu können. Sie können einen Typ einsetzen, der bereits in der FCL definiert ist, aber unter Umständen gibt es in der FCL keinen Typ, der sich genau für Ihren Fall eignet. Wahrscheinlich müssen Sie also Ihren eigenen Typ definieren, der direkt von System.Exception abgeleitet wird. Falls Sie eine Ausnahmetyphierarchie definieren wollen, wird dringend empfohlen, dass Sie diese Hierarchie flach und breit machen, das heißt, dass Sie so wenige Basisklassen verwenden wie möglich. Der Grund: Basisklassen bieten einen Mechanismus, viele Arten von Fehlern als einen einzigen Fehler zu behandeln, und das ist normalerweise gefährlich. Aus diesem Grund sollten Sie auch niemals ein System.Exception auslösen, und Sie sollten besonders vorsichtig sein, falls Sie irgendeinen anderen Basisklassenausnahmetyp auslösen. Welche Stringmeldung übergeben Sie an den Konstruktor des Ausnahmetyps? Wenn Sie eine Ausnahme auslösen, sollten Sie eine Stringmeldung mit detaillierten Informationen darüber bereitstellen, warum die Methode ihre Aufgabe nicht abschließen konnte. Wenn die Ausnahme abgefangen und behandelt wird, bekommt niemand diese Meldung zu sehen. Falls die Ausnahme aber eine unbehandelte Ausnahme wird, wird die Meldung normalerweise protokolliert. Eine unbehandelte Ausnahme ist ein echter Fehler in der Anwendung, und ein Entwickler muss diesen Fehler korrigieren. Ein Endbenutzer verfügt nicht über den Quellcode oder die Fähigkeit, den Code zu korrigieren und neu zu kompilieren. Ein Endbenutzer sollte diese Meldung eigentlich überhaupt nicht zu Gesicht bekommen. Daher darf die Meldung technisch sehr detailliert sein, nur Entwickler brauchen sie zu verstehen, um ihren Code korrigieren zu können. Und da alle Entwickler Englisch sprechen müssen (zumindest ein bisschen, da Programmiersprachen und die Klassen und Methoden der FCL englische Namen verwenden), gibt es normalerweise keinen Grund, die Meldungen in den Ausnahmestrings zu lokalisieren. Es kann allerdings sinnvoll sein, die Strings zu lokalisieren, falls Sie eine Klassenbibliothek erstellen, die von Entwicklern in unterschiedlichen Ländern benutzt wird. Microsoft lokalisiert die Meldungen der von der FCL ausgelösten Ausnahmen, da Entwickler auf der ganzen der Welt mit dieser Klassenbibliothek arbeiten. Definieren einer eigenen Ausnahmeklasse Nehmen wir an, Sie definieren eine Methode, die einen Verweis auf ein Objekt übergeben bekommt, dessen Typ die Schnittstellen IFormattable und IComparable implementieren muss. Diese Methode könnten Sie etwa so formulieren:

16 448 Kapitel 19: Ausnahmen internal sealed class SomeType { public void SomeMethod(Object o) { if (!((o is IFormattable) && (o is IComparable))) { throw new MissingInterfaceException(...); // Hier folgt der Code zum Verarbeiten von o.... Da die FCL keinen geeigneten Ausnahmetyp anbietet, müssen Sie selbst den Typ MissingInterface- Exception definieren. Beachten Sie, dass der Name eines Ausnahmetyps laut Konvention auf Exception enden sollte. Beim Definieren dieses Typs müssen Sie entscheiden, von welchem Basistyp er abgeleitet sein soll. Wählen Sie Exception, ArgumentException oder einen ganz anderen Typ? Ich habe Jahre damit verbracht, über diese Frage nachzudenken. Leider kann ich Ihnen keine Universallösung präsentieren. Ich will Ihnen aber zumindest erklären, warum es keine goldene Regel gibt: Der Grund sind die inhärenten Beschränkungen, die für jedes auf Vererbung basierende Objektmodell gelten. Falls Sie MissingInterfaceException von ArgumentException ableiten, fängt bereits vorhandener Code, der ArgumentException abfängt, auch Ihre neue Ausnahme ab. In gewisser Weise ist das ein Feature, andererseits aber ein Bug. Es ist ein Feature, weil jeder Programmcode, der alle Ausnahmen im Zusammenhang mit Argumenten abfängt (über ArgumentException), jetzt automatisch auch diese neue Argumentausnahme (MissingInterfaceException) abfängt. Es ist ein Bug, weil die Ausnahme MissingInterfaceException ein neues Ereignis ist, mit dem der Entwickler, der den Ausnahmehandler für die ArgumentException geschrieben hat, noch nicht gerechnet hat. Wenn Sie den Typ Missing- InterfaceException definieren, stufen Sie diese Ausnahme vielleicht als so ähnlich zu ArgumentException ein, dass sie auf dieselbe Weise behandelt werden sollte. Diese nicht vorhergesehene Verwandtschaft könnte aber unerwartetes Verhalten zur Folge haben. Falls Sie MissingInterfaceException andererseits direkt von Exception ableiten, löst Ihr Code einen neuen Ausnahmetyp aus, den die Anwendung noch nicht kennen konnte. Wahrscheinlich entwickelt sich daraus eine nicht behandelte Ausnahme, wegen der die Anwendung beendet wird. Das könnte ich natürlich einfach zu erwünschtem Verhalten erklären, weil eine Methode ihre Aufgabe nicht abschließen kann und die Anwendung nie dazu entwickelt wurde, mit diesem Problem fertig zu werden. Würde die Anwendung diese neue Ausnahme abfangen, ignorieren und einfach weiterlaufen, wären die Ergebnisse kaum vorherzusagen. Das könnte sogar eine Sicherheitslücke öffnen. Diese Fragen gehören zu den Gründen, warum Anwendungsentwicklung eher eine Kunst ist als eine Wissenschaft. Wenn Sie einen neuen Ausnahmetyp definieren, müssen Sie sorgfältig überlegen, in welcher Weise Anwendungscode Ihren Typ (oder den Basistyp Ihres Ausnahmetyps) abfängt. Wählen Sie dann den Basistyp, der für den Aufrufer die wenigsten negativen Folgen hat. Beim Definieren Ihrer Ausnahmetypen können Sie bei Bedarf ruhig eigene Unterhierarchien entwerfen. Sie können die Hierarchie direkt auf Exception aufbauen oder auf einen anderen Basistyp. Stellen Sie aber auch hier wieder sicher, dass Sie Ihre Unterhierarchie so platzieren, dass es für den Aufrufer am sinnvollsten ist. Falls Sie einen Ausnahmetyp definieren, der nicht als Basistyp für andere Ausnahmetypen dienen soll, können Sie den Typ als sealed kennzeichnen.

17 Definieren einer eigenen Ausnahmeklasse 449 Der Basistyp Exception definiert vier Standardkonstruktoren: Ein öffentlicher, parameterloser Konstruktor (Standardkonstruktor). Er legt eine Instanz des Typs an und trägt in alle Felder und Eigenschaften Standardwerte ein. Ein öffentlicher Konstruktor, der einen String übergeben bekommt. Er legt eine Instanz des Typs an und trägt eine bestimmte Meldung ein. Ein öffentlicher Konstruktor, der einen String und eine Instanz eines von Exception abgeleiteten Typs übergeben bekommt. Er legt eine Instanz des Typs an und trägt eine bestimmte Meldung sowie eine verschachtelte Ausnahme ein. Ein geschützter Konstruktor, der ein SerializationInfo und ein StreamingContext übergeben bekommt. Er deserialisiert Instanzen des von Exception abgeleiteten Objekts. Beachten Sie, dass diese Methode private sein sollte, falls der von Exception abgeleitete Typ versiegelt ist, und stellen Sie sicher, dass der Konstruktor denselben Konstruktor in der Basisklasse aufruft, damit auch die Felder der Basisklasse korrekt deserialisiert werden. Wenn Sie Ihren eigenen Ausnahmetyp definieren, sollte dieser Typ alle vier Konstruktoren implementieren und darin jeweils den entsprechenden Konstruktor des Basistyps aufrufen. Natürlich erbt Ihr Ausnahmetyp alle Felder und Eigenschaften, die Exception definiert. Sie können weitere Felder und Eigenschaften zu Ihrem Typ hinzufügen. Als zum Beispiel der Typ System.ArgumentException definiert wurde, fügte er eine String-Eigenschaft namens ParamName hinzu (zu allem, was er vom Typ Exception geerbt hat). Der Typ ArgumentException definiert neue Konstruktoren (neben den vier Standardkonstruktoren), die einen zusätzlichen String-Parameter haben, mit dem die Eigenschaft ParamName initialisiert wird. Diese Eigenschaft gibt den Namen des Parameters an, bei dem die Voraussetzungen der Methode verletzt wurden. Wird die Ausnahme ArgumentException abgefangen, kann der Ausnahmehandler die Eigenschaft ParamName auslesen und so ermitteln, welcher Parameter das Problem verursacht hat. Ich kann Ihnen versichern, dass dies unheimlich praktisch ist, wenn Sie eine Anwendung debuggen. Falls Sie Felder zu Ihrem Ausnahmetyp hinzufügen, müssen Sie Konstruktoren definieren, mit denen die Felder initialisiert werden. Außerdem sollten Sie unbedingt Eigenschaften oder andere Member definieren, die die Werte der Felder an den Anwendungscode zurückgeben können, der Ihren Ausnahmetyp abfängt. Von Exception abgeleitete Typen sollten immer serialisierbar sein, damit das Ausnahmeobjekt über die Grenzen einer AppDomain gemarshalt werden kann. Dadurch kann der Ausnahmetyp auch in einem Protokoll oder einer Datenbank gespeichert werden. Es sind zwei Schritte erforderlich, um Ihren Ausnahmetyp serialisierbar zu machen: Erstens müssen Sie ihn mit dem benutzerdefinierten Attribut [Serializable] kennzeichnen. Zweitens müssen Sie die Schnittstelle ISerializable mit ihrer Methode GetObjectData (der ein SecurityPermission-Attribut zugeordnet ist) und einen Konstruktor definieren. Methode und Konstruktor haben je einen SerializationInfo- und einen StreamingContext-Parameter. Falls die Klasse sealed ist, muss der Konstruktor private sein. Andernfalls muss der Konstruktor protected sein. Das folgende Codebeispiel zeigt, wie Sie Ihren Ausnahmetyp korrekt definieren: using System; using System.Text; using System.Runtime.Serialization; using System.Security.Permissions;

18 450 Kapitel 19: Ausnahmen // Instanzen von DiskFullException sollen serialisierbar sein. [Serializable] public sealed class DiskFullException : Exception, ISerializable { // Ein privates Feld definieren. private String m_diskpath; // Eine schreibgeschützte Eigenschaft, die das Feld zurückgibt. public String DiskPath { get { return m_diskpath; // Die öffentliche Eigenschaft Message überschreiben, sodass unser Feld // (sofern ihm ein Wert zugewiesen wurde) in der Meldung enthalten ist. public override String Message { get { if (m_diskpath == null) return base.message; StringBuilder msg = new StringBuilder(base.Message); msg.appendformat( " (DiskPath={0){1", m_diskpath, Environment.NewLine); return msg.tostring(); // Die drei öffentlichen Konstruktoren public DiskFullException() : base() { public DiskFullException(String message) : base(message) { public DiskFullException(String message, Exception innerexception) : base(message, innerexception) { // Zusätzliche Konstruktoren zum Setzen des Feldes definieren. public DiskFullException(String message, String diskpath) : this(message) { m_diskpath = diskpath; public DiskFullException(String message, String diskpath, Exception innerexception) : this(message, innerexception) { m_diskpath = diskpath; // Der eine Konstruktor für die Deserialisierung. // Weil diese Klasse versiegelt ist, ist dieser Konstruktor privat. // Wäre die Klasse nicht versiegelt, sollte der Konstruktor geschützt sein. private DiskFullException(SerializationInfo info, StreamingContext context) : base(info, context) { // Jedes Feld deserialisieren. m_diskpath = info.getstring("diskpath"); // Die Methode für die Serialisierung. Die SecurityPermission stellt sicher, dass // Aufrufer die Berechtigung haben, den internen Zustand dieses Objekts zu ermitteln. [SecurityPermission(SecurityAction.Demand, SerializationFormatter = true)] public override void GetObjectData( SerializationInfo info, StreamingContext context) { // Der Basistyp soll seine Felder serialisieren. base.getobjectdata(info, context); // Felder dieses Typs serialisieren. info.addvalue("diskpath", m_diskpath);

19 Wie Sie Ausnahmen richtig einsetzen 451 Wie Sie Ausnahmen richtig einsetzen Sicherlich ist es wichtig, dass Sie wissen, wie die Ausnahmebehandlung funktioniert. Genauso wichtig ist, dass Sie verstehen, wie Sie Ausnahmen sinnvoll einsetzen. Nur zu oft stelle ich fest, dass Entwickler von Bibliotheken alle möglichen Ausnahmen abfangen und so den Anwendungsentwicklern die Tatsache vorenthalten, dass ein Problem aufgetreten ist. In diesem Abschnitt fasse ich einige Richtlinien zusammen, die Ihnen beim Einsatz von Ausnahmen bewusst sein sollten. WICHTIG Falls Sie eine Klassenbibliothek entwickeln und Typen entwerfen, die von anderen Programmierern benutzt werden, sollten Sie diese Richtlinien genau beachten. Sie tragen eine große Verantwortung: Sie versuchen, die Schnittstelle des Typs so zu entwerfen, dass sie für eine große Bandbreite von Anwendungen sinnvoll ist. Sie kennen die Interna des Codes, den Sie zurückrufen (über Delegaten, virtuelle Methoden oder Schnittstellenmethoden), nicht genau. Und Sie wissen nicht, welcher Code Ihre Bibliothek aufrufen wird. Sie können unmöglich jede Situation vorhersehen, in der Ihr Typ eingesetzt wird. Treffen Sie daher keine vorschnellen Entscheidungen. Ihr Code darf nicht bewerten, welche Bedingung ein Fehler ist und welche nicht, das ist die Aufgabe des aufrufenden Codes. Wenn Sie sich an die Richtlinien in diesem Kapitel halten, wird es für andere Entwickler leichter, die Typen in Ihrer Klassenbibliothek zu benutzen. Entwickeln Sie eine Anwendung, können Sie nach Belieben eine geeignete Richtlinie definieren. Wenn Sie den Richtlinien in diesem Kapitel folgen, können Sie Probleme in Ihrem Code aufspüren, bevor er ausgeliefert wird. Sie können die Probleme dann rechtzeitig beseitigen und Ihre Anwendung robuster machen. Sie können aber durchaus von den Richtlinien abweichen, wenn Sie sich nach sorgfältiger Überlegung dafür entschieden haben. Sie können die Richtlinie selbst festlegen. Zum Beispiel kann Anwendungscode beim Abfangen von Ausnahmen aggressiver vorgehen. Überprüfen Sie die Argumente Ihrer Methode Bei öffentlichen Typen, die Teil einer wieder verwendbaren Klassenbibliothek werden, wird dringend empfohlen, die Argumente der öffentlichen und geschützten Methoden zu überprüfen, bevor die Methode versucht, irgendeine Operation durchzuführen. Dafür gibt es zwei Gründe. Erstens können Entwickler, die die Methode aufrufen, sicher sein, dass sie die Methode korrekt aufrufen. Zweitens ist es viel wahrscheinlicher, dass die Methode ihre Aufgaben abschließt, falls alle Argumente korrekt sind. Die Gefahr, dass die Methode eine Ausnahme auslöst, ist geringer. Das bedeutet auch, dass die Wahrscheinlichkeit größer ist, dass Objekte in einem konsistenten Zustand bleiben. Betrachten wir als Beispiel noch einmal die öffentliche, statische Methode Transfer des Typs Account (aus dem Abschnitt»Was genau ist eine Ausnahme?«auf S. 441 in diesem Kapitel). Diese Methode überweist Geld von einem Konto auf ein anderes. Falls diese Methode ihre Argumente nicht sofort überprüft, könnte sie Geld vom Absenderkonto from erfolgreich abbuchen, dann aber feststellen, dass das Argument für das Empfängerkonto to den Wert null hat. An diesem Punkt würde die Methode eine Ausnahme auslösen, weil sie das Geld nicht überweisen kann. Die Methode muss aber auch das Geld wieder dem Konto from zuschreiben. Falls sie das nicht tut, ist der Saldo des Kontos from falsch. Wenn eine Methode ihre Argumente möglichst früh überprüft, ist die Programmierung einfacher, weil der Entwickler sich nicht mehr damit beschäftigen muss, was er bei einer abgebrochenen Transaktion oder anderen komplexen Bedingungen tun soll. Wenn Sie eine Methode in einer wieder verwendbaren Klasse implementieren, sollte die Methode ihre Argumente überprüfen. Entdeckt sie ein ungültiges Argument, sollte sie eine Ausnahme auslösen, die von System.ArgumentException abgeleitet ist. Die nützlichste der von System.ArgumentException abgeleiteten Ausnahmeklassen sind System.ArgumentNullException, System.ArgumentOutOfRangeEx-

20 452 Kapitel 19: Ausnahmen ception und System.DuplicateWaitObjectException. Falls sich keine dieser Ausnahmen für Ihren Fall eignet, können Sie entweder Ihren eigenen Ausnahmetyp definieren, der von ArgumentException abgeleitet ist, oder Sie können einfach ArgumentException selbst auslösen. Beachten Sie, dass auch System.ComponentModel.InvalidEnumArgumentException von ArgumentException abgeleitet ist, Microsoft stuft diesen Ausnahmetyp aber als Irrtum ein und rät davon ab, ihn zu benutzen, weil er in einem ungewöhnlichen Namespace liegt und in System.dll definiert ist statt in MSCorLib.dll. HINWEIS Falls Ihre Methoden ihre Argumente gleich am Anfang überprüfen, sollten Sie weniger Debug.Assert- Aufrufe in Ihren Code einfügen. Sie sollten eine Assert-Anweisung als Entwicklungswerkzeug betrachten, mit dem Sie bestimmte Annahmen für Ihre eigene Assembly überprüfen, die immer zutreffen soll. Eine Assert-Anweisung kann Ihnen helfen, bestimmte Programmierfehler schon während der Entwicklung aufzudecken, sodass Sie den Quellcode korrigieren, neu erstellen und die neue Version testen können. Es gibt niemals Code, der eine fehlgeschlagene Assert- Anweisung abfängt und die Ursache korrigiert. Denken Sie daran, dass Debug.Assert bei einem Releasebuild aus dem Code verschwunden ist, Ausnahmen aber immer noch ausgelöst werden. Aus diesen und anderen Gründen sollte eine Assembly nicht Debug.Assert-Aufrufe benutzen, um sicherzustellen, dass Code in einer anderen Assembly eine Methode auf korrekte Weise aufruft. Für diesen Zweck sollten Sie Ausnahmen benutzen. Es kann allerdings sinnvoll sein, Aufrufe von Debug.Assert zusätzlich einzufügen, auch wenn Sie eine Ausnahme auslösen, denn eine fehlgeschlagene Assert-Anweisung ermöglicht Ihnen, den Debugger direkt mit dem fehlgeschlagenen Code zu verbinden und so bequem das Argument und die lokalen Variablen zu untersuchen. Wo wir schon beim Thema Argumentüberprüfung sind, möchte ich auf einen sehr wichtigen Punkt hinweisen. Wie Sie wissen, kann eine Methode so deklariert sein, dass sie sowohl Werttyp- als auch Verweistypparameter hat. Wenn Werttypargumente übergeben werden, kann der Code innerhalb der Methode den Wert, den das Argument außerhalb der Methode hat, nicht ändern. Werden dagegen Verweistypargumente an eine Methode übergeben, kann die Methode das tatsächliche Objekt, auf das das Argument verweist, ändern, sodass es außerhalb der Methode einen anderen Wert bekommt (das gilt nicht für String-Objekte, da Strings unveränderlich sind). Das kann zum Beispiel in einer Multithreading-Anwendung von Bedeutung sein. Wenn Sie eine sichere und robuste Klassenbibliothek erstellen wollen, sollten Methoden, die veränderbare Verweistypen als Argumente übernehmen, eine Kopie dieser Argumente anlegen, die Kopie überprüfen und dann innerhalb der Methode mit der Kopie arbeiten. So ist sichergestellt, dass die Methode mit unveränderlichen Eingabendaten arbeitet. Der folgende Code demonstriert das potentielle Problem: #define BADCODE using System; using System.Threading; public static class Program { public static void Main() { Int32[] denominators = { 1, 2, 3 ; // Ein anderer Thread erledigt die Arbeit. ThreadPool.QueueUserWorkItem(Divide100By, denominators); // DEMO: Divide100By bekommt die Gelegenheit, die Arrayelement zu überprüfen. Thread.Sleep(50);