{"id":55000037,"date":"2016-06-01T00:00:00","date_gmt":"2024-04-25T16:15:09","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=37"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Von_VBA_zu_C_Fehlerbehandlung","status":"publish","type":"post","link":"https:\/\/vbentwickler.de\/Von_VBA_zu_C_Fehlerbehandlung\/","title":{"rendered":"Von VBA zu C#: Fehlerbehandlung"},"content":{"rendered":"

\"\"<\/p>\n

Nur wenige Access-Programmierer statten ihre Anwendungen mit einer ordentlichen Fehlerbehandlung aus. Für viele ist dies ein leidiges Thema. Die Fehlerbehandlung sorgt im Optimalfall sowohl unter VBA als auch unter C# dafür, dass eine Anwendung stabiler wird und nach dem Auftreten von Laufzeitfehlern nicht unerwartet reagiert oder sogar abstürzt. Während es unter VBA nur wenige Konstrukte gibt, um eine Fehlerbehandlung zu implementieren, bietet C# schon eine Menge mehr. Dieser Artikel liefert eine Einführung und zeigt, wie Sie die von VBA gewohnten Techniken unter C# einsetzen.<\/b><\/p>\n

Die minimale Fehlerbehandlung unter VBA sieht so aus, dass Sie vor fehlerträchtigen Anweisungen die eingebaute Fehlerbehandlung mit der folgenden Programmzeile deaktivieren:<\/p>\n

On Error Resume Next<\/span><\/pre>\n
Alle folgenden Fehler in der aktuellen Routine und in solchen, die von dieser Routine aufgerufen werden, werden nicht behandelt. Dadurch gibt es zwar immerhin keine Fehlermeldung und es werden keine Variablen geleert, was beim Auftreten unbehandelter Fehler auftreten kann. Allerdings erledigen fehlerhafte Zeilen ihre Aufgabe nicht, was zu Folgefehlern (auch logischen Fehlern) in den folgenden Anweisungen führen kann.<\/p>\n
Spätestens mit dem Ende der Routine endet die Deaktivierung der eingebauten Fehlerbehandlung. Vorher erhalten Sie dies mit der folgenden Anweisung:<\/p>\n
On Error Goto 0<\/pre>\n
Dadurch reagiert VBA wieder wie gewohnt mit entsprechenden Fehlermeldungen auf Fehler.<\/p>\n
Dazwischen haben Sie Gelegenheit, benutzerdefiniert auf die auftretenden Fehler zu reagieren – beispielsweise, indem Sie den Wert der Eigenschaft Number <\/b>des Err<\/b>-Objekts auslesen und für die interessanten Werte entsprechende Fehlerbehandlungen hinzufügen.<\/p>\n
Dies kann beispielsweise wie folgt aussehen:<\/p>\n
On Error Resume Next<\/span>\r\nDebug.Print<\/span> 1\/0\r\nSelect Case Err.Number\r\n     Case <\/span>11\r\n         MsgBox<\/span> \"Fehler: Teilen durch 0.\"\r\nEnd Select<\/span>\r\nOn Error Goto 0<\/pre>\n
Unter C# gibt es zur Fehlerbehandlung andere Möglichkeiten, die Sie in den folgenden Abschnitten kennen lernen.<\/p>\n
Warum überhaupt eine Fehlerbehandlung?<\/h2>\n
Um auf Nummer sicher zu gehen, wollen wir zuvor noch einmal kurz auf die Gründe für die Programmierung einer benutzerdefinierten Fehlerbehandlung eingehen. Wenn Sie Code programmieren, der fehlerhafte Eingaben zulässt und keine entsprechende benutzerdefinierte Fehlerbehandlung aufweist, erhalten Sie beispielsweise bei einer Konsolenanwendung eine Meldung plus Fehlerbehandlungsfenster wie in Bild 1.<\/p>\n
\"Unbehandelte<\/p>\n
Bild 1: Unbehandelte Ausnahme bei einer Konsolenanwendung<\/span><\/b><\/p>\n
Wenn Sie einen solchen Fehler in einer WPF-Anwendung auslösen, erhalten Sie noch nicht einmal einen kleinen Hinweis auf den Fehler im Code, der zu dieser Ausnahme führte (siehe Bild 2).<\/p>\n
\"Unbehandelte<\/p>\n
Bild 2: Unbehandelte Ausnahme bei einer Windows-Anwendung<\/span><\/b><\/p>\n
Noch übler wird es, wenn nicht Sie selbst die Software bedienen, sondern ein Kunde: Erstens macht dies nie einen guten Eindruck, zweitens kann der Kunde auf Basis der hier gelieferten Fehlerinformationen kaum helfen, den Fehler zu finden.<\/p>\n
Also sollten Sie dafür sorgen, dass der Kunde einen aussagekräftigen Text als Fehlermeldung erhält, der ihn beispielsweise bei einem Eingabefehler auf die Ursache des Fehlers hinweist oder aber ihm die Informationen liefert, die er zur Behebung des Problems an den Entwickler der Software weitergeben kann.<\/p>\n
Der wichtigste Punkt beim Implementieren einer benutzerdefinierten Fehlerbehandlung etwa unter VBA ist jedoch die stabile Fortsetzung der Anwendung: Wenn ein Fehler aufgetreten ist, beispielsweise durch eine Fehleingabe oder einen fehlerhaften Zugriff auf ein Element, dann sollte die Anwendung nach der Ausgabe der Fehlermeldung fortgesetzt werden können und nicht einfach abbrechen. Dabei ist außerdem sicherzustellen, dass die Funktion und der stabile Zustand der Anwendung durch den Fehler nicht beeinträchtigt werden. Bei VBA war das mitunter ganz einfach deshalb nicht der Fall, weil durch unbehandelte Fehler Variableninhalte gelöscht oder Objekte zerstört wurden. Wurden die Zeilen, die den Fehler auslösten, hingegen per On Error Resume Next <\/b>einer benutzerdefinierten Fehlerbehandlung zugeführt, statt einfach unbehandelte Fehler auszulösen, war zumindest schon einmal der Inhalt und der Zustand der Variablen sichergestellt.<\/p>\n
Fehlerhafter Code<\/h2>\n
Schauen wir uns das Beispiel an, das zum Auslösen der Ausnahme der Konsolenanwendung führte. Den Code finden Sie in Listing 1. Die Zeile, die das Ergebnis der Division der Werte der Variablen Dividend <\/b>und Divisor <\/b>ermitteln soll, löst die Ausnahme aus, wenn der Divisor zuvor den Wert 0 <\/b>zugewiesen bekommen hat – der Fehler tritt also durch eine Division durch 0 <\/b>auf.<\/p>\n
static void Main(string[] args) {\r\n     Console.WriteLine(\"Geben Sie den Dividend und den Divisor als ganze Zahlen ein.\");\r\n     Console.WriteLine(\"Dividend:\");\r\n     decimal Dividend = Convert.ToDecimal(Console.ReadLine());\r\n     Console.WriteLine(\"Divisor:\");\r\n     decimal Divisor = Convert.ToDecimal (Console.ReadLine());\r\n     decimal Quotient = Dividend \/ Divisor;\r\n     Console.WriteLine(\"Der Quotient lautet: {0}\", Quotient);\r\n     Console.ReadLine();\r\n}<\/pre>\n
Listing 1: Methode, die einen Fehler auslöst, wenn als Divisor der Wert 0 angegeben wird<\/span><\/b><\/p>\n
Wenn Sie die Anwendung debuggen, also diese von Visual Studio aus etwa mit der Taste F5 <\/b>starten, erhalten Sie einige Fehlerinformationen mehr. Außerdem markiert Visual Studio gleich die fehlerhafte Zeile (siehe Bild 3). Es gibt sogar noch Tipps zur Problembehandlung.<\/p>\n
\"Auslösen<\/p>\n
Bild 3: Auslösen einer Ausnahme unter C#<\/span><\/b><\/p>\n
Wenn Sie möchten, erhalten Sie auch noch weitere Details, und zwar durch einen Mausklick auf den Link Details anzeigen …<\/b>, der den Dialog aus Bild 4 öffnet.<\/p>\n
\"Details<\/p>\n
Bild 4: Details zu einer Ausnahme beim Debuggen in Visual Studio<\/span><\/b><\/p>\n
Für Fehler wie diese gibt es einige Beispiele – die Eingabe unzulässiger Werte wie in diesem Beispiel, Zugriff auf nicht vorhandene Dateien et cetera.<\/p>\n
try…catch statt On Error Resume Next<\/h2>\n
Unter C# können Sie Laufzeitfehler in sogenannten try…catch<\/b>-Blöcken behandeln. Das sieht dann so aus, dass Sie den Code, der einen Fehler auslösen könnte, in den try<\/b>-Block packen und den Code, der ausgelöst werden soll, wenn innerhalb des try<\/b>-Blocks ein Fehler auftritt, in den catch<\/b>-Block.<\/p>\n
In unserem Fall wollen wir die Zeile, welche die Division durchführt, in den try<\/b>-Block überführen. Gleichzeitig fügen wir dort auch die Zeile ein, welche das Ergebnis aus der Variablen Quotient <\/b>in der Konsole ausgibt – sonst ergibt dies einen Syntaxfehler, weil Quotient <\/b>nicht in jedem Falle deklariert und initialisiert wird.<\/p>\n
In den catch<\/b>-Block schreiben wir eine Anweisung, welche einen Hinweis auf das Auftreten eines Fehlers in der Konsole ausgibt (siehe Listing 2). Wie Sie hier erkennen, wird die folgende Anweisung, die ja das Ergebnis der Berechnung ausgeben sollte, ignoriert – dies gilt grundsätzlich für alle Anweisungen, die der fehlerhaften Anweisung folgen.<\/p>\n
try {\r\n     decimal Quotient = Dividend \/ Divisor;\r\n     Console.WriteLine(\"Der Quotient lautet: {0}\", Quotient);\r\n}\r\ncatch {\r\n     Console.WriteLine(\"Ups! Es ist ein Fehler beim Rechnen aufgetreten!\");\r\n}<\/pre>\n
Listing 2: Abfangen eines Fehlers per try…catch-Block<\/span><\/b><\/p>\n
Nun erhält der Benutzer zwar auch keine wesentlich aussagekräftigere Meldung, aber dafür wird das Programm auch nicht einfach abgebrochen. Außerdem haben wir ja auch noch gar nicht geprüft, um was für einen Fehler es sich handelt – dies prüfen wir in der folgenden Version.<\/p>\n
Die Anwendung wird dann mit den Anweisungen fortgesetzt, die nach dem Ende des catch<\/b>-Blocks folgen. Dies erkennen Sie in diesem Beispiel daran, dass das Betätigen der Eingabetaste das Programm beendet, weil die letzte Console.ReadLine()<\/b>-Methode ausgeführt wird (siehe Bild 5).<\/p>\n
\"Benutzerdefinierte<\/p>\n
Bild 5: Benutzerdefinierte Fehlermeldung beim Auftreten der Ausnahme<\/span><\/b><\/p>\n
Exception statt Err<\/h2>\n
Unter C# heißt das Objekt, das die per Code auswertbaren Fehlerinformationen enthält, Exception<\/b>. Es entspricht etwa dem Objekt Err <\/b>unter VBA, das ja mit seinen Eigenschaften Description <\/b>oder Number <\/b>oft hilfreiche Informationen liefert.<\/p>\n
Damit Sie dieses Objekt nutzen können, müssen Sie es für den catch<\/b>-Zweig als Parameter hinzufügen, also wie in Listing 3 mit catch (Exception e)<\/b>.<\/p>\n
catch (Exception e) {\r\n     Console.WriteLine(\"Meldung des Exception-Objekts:\\n{0}\\n\", e.Message);\r\n     Console.WriteLine(\"Umfangreiche Informationen:\\n{0}\\n\", e.GetBaseException().ToString());\r\n     Console.WriteLine(\"Typ der Ausnahme:\\n{0}\", e.GetType().ToString());\r\n}<\/pre>\n
Listing 3: Ausstatten des catch-Block mit einigen weiteren Informationen<\/span><\/b><\/p>\n
Die folgenden drei Zeilen des Beispiels geben verschiedene Informationen auf die Konsole aus, die Sie auch in Bild 6 sehen. Die erste ist der Inhalt der Eigenschaft Message<\/b>. Die Eigenschaft GetBaseException <\/b>liefert den Text, den auch ein unbehandelter Fehler auf die Konsole zaubert. Schließlich gibt uns die Eigenschaft GetType <\/b>hilfreiche Informationen, wenn es darum geht, den Typ der Ausnahme zu ermitteln. In diesem Fall lautet der Typ DivideByZeroException<\/b>. Damit können wir später gezielt auf bestimmte Fehler reagieren.<\/p>\n
\"Erweiterte<\/p>\n
Bild 6: Erweiterte Fehlermeldung des Exception-Objekts<\/span><\/b><\/p>\n
Allgemeine Exception<\/h2>\n
Was wir im vorherigen Beispiel getan haben, war die Behandlung einer allgemeinen Exception. Die Klasse Exception <\/b>ist quasi die Mutter aller Fehlerklassen. Es gibt eine ganze Reihe von Fehlerklassen, die von dieser Klasse abgeleitet sind.<\/p>\n
Wenn Sie im catch<\/b>-Zweig einer Ausnahmebehandlung in Klammern ein Objekt des Typs Exception <\/b>übergeben, fangen Sie damit alle möglichen Ausnahmen ab. Dies entspricht etwa dem Case Else<\/b>-Zweig in einer VBA-Fehlerbehandlung wie der folgenden:<\/p>\n
Select Case Err.Number\r\n     Case <\/span>11 ''Geteilt durch Null\r\n         ''Fehler behandeln\r\n     Case <\/span>0 ''kein Fehler, nichts ist zu tun\r\n     Case Else<\/span>\r\n         ''Alle übrigen Fehlernummern behandeln\r\nEnd Select<\/span><\/pre>\n
Nun wollen wir noch wissen, wie wir einen speziellen Fehler abfangen, in diesem Fall die DivideByZeroException<\/b>. Wenn Sie nur diesen einen Fehler abfangen möchten, reicht die folgende Variante aus:<\/p>\n
try {\r\n     decimal Quotient = Dividend \/ Divisor;\r\n     Console.WriteLine(\"Der Quotient lautet: {0}\", Quotient);\r\n}\r\ncatch (DivideByZeroException e) {\r\n     Console.WriteLine(\"Der Dividend darf nicht 0 sein.\");\r\n}<\/pre>\n
Der catch<\/b>-Zweig wird in diesem Fall nur angesteuert, wenn eine DivideByZero<\/b>-Ausnahme ausgelöst wird. Im Falle eines jeden anderen Fehlers tritt eine unbehandelte Ausnahme auf.<\/p>\n
Um einen weiteren, andersartigen Fehler auszulösen und behandeln zu können, ziehen wir die übrigen Anweisungen der Methode wie in Listing 4 ebenfalls in den try<\/b>-Block hinein. Außerdem fügen wir neben dem catch<\/b>-Block, der sich um den Fehler kümmert, der beim Teilen durch 0 <\/b>auftritt, einen weiteren catch<\/b>-Block hinzu. Dieser soll wieder alle übrigen Fehler abfangen.<\/p>\n
public static void Andere_Exception() {\r\n     try {\r\n         Console.WriteLine(\"Geben Sie den Dividend und den Divisor als ganze Zahlen ein.\");\r\n         Console.WriteLine(\"Dividend:\");\r\n         decimal Dividend = Convert.ToDecimal(Console.ReadLine());\r\n         Console.WriteLine(\"Divisor:\");\r\n         decimal Divisor = Convert.ToDecimal(Console.ReadLine());\r\n         decimal Quotient = Dividend \/ Divisor;\r\n         Console.WriteLine(\"Der Quotient lautet: {0}\", Quotient);\r\n     }\r\n     catch (DivideByZeroException e) {\r\n         Console.WriteLine(\"Der Dividend darf nicht 0 sein.\");\r\n     }\r\n     catch (Exception e) {\r\n         Console.WriteLine(\"Es ist ein Fehler aufgetreten: {0}\", e.GetType().ToString());\r\n     }\r\n     Console.ReadLine();\r\n}<\/pre>\n
Listing 4: Abfangen eines speziellen und eines allgemeinen Fehlers per try…catch-Block<\/span><\/b><\/p>\n
Wenn wir nun beispielsweise für die erste Console.ReadLine<\/b>-Anweisung keine Zahl, sondern eine Zeichenkette eingeben, erhalten wir einen weiteren Fehler. Dieser wird ausgelöst, da wir das Ergebnis der Eingabe direkt in einen Wert des Datentyps decimal <\/b>umwandeln wollen. Das gelingt mit einer Zeichenkette natürlich nicht, also liefert dies eine weitere Ausnahme – wie Bild 7 zeigt.<\/p>\n
\"Fehler<\/p>\n
Bild 7: Fehler durch die Eingabe von Daten im falschen Format<\/span><\/b><\/p>\n
Nachdem wir wissen, dass dies die Ausnahme FormatException <\/b>auslöst, fügen wir auch diese als weiteren catch<\/b>-Block zur Fehlerbehandlung hinzu:<\/p>\n
try {\r\n     ...\r\n}\r\ncatch (DivideByZeroException e) {\r\n     Console.WriteLine(\"Der Dividend darf nicht 0 sein.\");\r\n}\r\ncatch (FormatException e) {\r\n     Console.WriteLine(\"Bitte geben Sie eine ganze Zahl ein.\");\r\n}\r\ncatch (Exception e) {\r\n     Console.WriteLine(\"Es ist ein Fehler aufgetreten: \r\n         {0}\", e.GetType().ToString());\r\n}<\/pre>\n
Auf ähnliche Weise legen wir für alle Fehler, die auftreten können, eine Ausnahmebehandlung an (zumindest für die, die wir bereits erkennen können – der Benutzer wird sicher noch weitere Schwachstellen aufdecken …).<\/p>\n
Die Reihenfolge der catch<\/b>-Blöcke spielt natürlich eine übergeordnete Rolle, gerade wenn Sie eine allgemeine Ausnahmebehandlung (mit catch (Exception e)<\/b>) und speziellere Ausnahmebehandlungen (wie mit catch (DivideByZeroException)<\/b>) implementieren. Die catch-Blöcke werden nämlich immer in der angegebenen Reihenfolge abgearbeitet. Wenn Sie also direkt in der ersten catch<\/b>-Anweisung auf die allgemeine Ausnahme Exception <\/b>prüfen, wird diese bei jeder denkbaren Ausnahme angesteuert, da ja alle anderen Ausnahmen von Exception <\/b>erben. Aber Visual Studio beugt dem direkt vor, denn untergeordnete Ausnahmen müssen immer vor übergeordneten Ausnahmen abgearbeitet werden. Wenn wir versuchen, die allgemeine Exception<\/b>-Ausnahme vor der DivideByZeroException<\/b>-Ausnahme zu behandeln, erhalten wir einen Kompilierfehler (siehe Bild 8).<\/p>\n
\"Exceptions<\/p>\n
Bild 8: Exceptions müssen in der Hierarchie von unten nach oben abgearbeitet werden.<\/span><\/b><\/p>\n
Hierarchie der Exceptions<\/h2>\n
Damit kommen wir zurück zur Mutter aller Fehlerklassen und den untergeordneten Elementen. Woher erfahren wir, in welcher Hierarchie-Ebene sich eine …Exception<\/b>-Klasse befindet und welche die übergeordneten Klassen sind?<\/p>\n
Dazu klicken Sie etwa im Code-Fenster mit der rechten Maustaste auf den Text DivideByZeroException <\/b>und wählen dort den Eintrag Definition einsehen <\/b>aus. Dies öffnet einen gelb hinterlegten Bereich, der die öffentliche Klasse beschreibt, die von der Klasse ArithmeticException <\/b>abgeleitet ist (siehe Bild 9). Diese Abhängigkeit erkennen Sie an dem Doppelpunkt zwischen den beiden Klassennamen (DivideByZeroException : ArithmeticException<\/b>).<\/p>\n
\"Die<\/p>\n
Bild 9: Die Definition einer Klasse liefert Hinweise auf die übergeordnete Klasse<\/span><\/b><\/p>\n
Die Klasse ArithmeticException <\/b>wird also vermutlich sämtliche Ausnahmen behandeln, die durch die Verwendung von Rechenoperatoren unter C# ausgelöst werden, wobei DivideByZeroException <\/b>nur ein Spezialfall ist.<\/p>\n
Es geht aber noch weiter: Wenn Sie in der Definition mit der rechten Maustaste auf den Eintrag ArithmeticException <\/b>klicken und dann wiederum den Kontextmenü-Eintrag Definition einsehen <\/b>auswählen, erhalten Sie die Definition der Klasse ArithmeticException <\/b>und mit SystemException <\/b>die übergeordnete Ausnahmeklasse. Dass die Hierarchie einigermaßen flach ist, erkennen Sie, wenn Sie auch noch die übergeordnete Klasse von SystemException <\/b>ermitteln – hier landen Sie dann nämlich bei der Klasse Exception<\/b>, die keine weitere übergeordnete Ausnahmeklasse besitzt.<\/p>\n
Exception mit oder ohne Variable?<\/h2>\n
In allen bisherigen Beispielen haben wir das Exception<\/b>-Objekt in einer Variablen namens e <\/b>gespeichert, um innerhalb des catch<\/b>-Blocks auf die Eigenschaften des Ausnahme-Objekts zugreifen zu können. Diese Variable können Sie auch weglassen, wenn Sie gar nicht auf die Eigenschaften zugreifen wollen. Meist ist dies nicht notwendig – im Falle der DivideByZeroException <\/b>etwa gibt es in der betroffenen Methode ja nur eine Zeile, die diesen Fehler auslösen kann, und der Grund dafür ist dann auch offensichtlich. Sie können e also auch einfach weglassen:<\/p>\n
...\r\ncatch (DivideByZeroException) {\r\n     Console.WriteLine(\"Der Dividend darf nicht 0 sein.\");\r\n}\r\n...<\/pre>\n
In diesem Fall erscheinen dann auch keine Warnungen wie Die Variable “e” ist deklariert, wird aber nie verwendet.<\/b> mehr in der Fehlerliste von Visual Studio.<\/p>\n
Ausnahme in übergeordneter Methode verarbeiten<\/h2>\n
Manchmal möchten Sie Fehler direkt an Ort und Stelle verarbeiten, also beispielsweise in der Methode, in der die Ausnahme ausgelöst wurde. Es kann jedoch auch Fälle geben, wo die Ausnahme in einer übergeordneten Methode behandelt werden soll – also in der Methode, von der aus die untergeordnete Methode aufgerufen wurde.<\/p>\n
Ein Beispiel finden Sie in Listing 5. Hier ruft die Methode FehlerbehandlungUebergeordnet <\/b>die Methode FehlerbehandlungUntergeordnet <\/b>auf, packt aber diesen Aufruf in einen try<\/b>-Block. Was geschieht nun? Obwohl die Methode FehlerbehandlungUntergeordnet <\/b>keine eigene Behandlung von Ausnahmen enthält, wird der Fehler aufgrund der Fehlerbehandlung in der übergeordneten Fehlerbehandlung behandelt.<\/p>\n
public static void FehlerbehandlungUebergeordnet() {\r\n     try {\r\n         FehlerbehandlungUntergeordnet();\r\n     }\r\n     catch (Exception e) {\r\n         Console.WriteLine(\"Es ist ein Fehler aufgetreten: {0}\", e.GetType().ToString());\r\n     }\r\n}\r\nprivate static void FehlerbehandlungUntergeordnet() {\r\n     decimal Null = 0;\r\n     decimal Quotient = 1 \/ Null;\r\n     Console.WriteLine(\"Der Quotient lautet: {0}\", Quotient);\r\n     Console.ReadLine();\r\n}<\/pre>\n
Listing 5: Fehler in untergeordneter Methode behandeln<\/span><\/b><\/p>\n
Natürlich können Sie auch noch eine individuelle Ausnahme-Behandlung zur untergeordneten Methode hinzufügen. Dies würde dann etwa wie in Listing 6 aussehen. Hier wird der Fehler, der durch die Division durch 0 <\/b>auftritt, direkt an Ort und Stelle behandelt. Alle anderen Fehler, also beispielsweise durch Eingeben eines Textes statt einer Zahl, werden in der allgemeinen Ausnahmebehandlung in der übergeordneten Methode behandelt. Wenn Sie auf diese Weise mehrere Methoden von der Hauptmethode aus aufrufen, brauchen Sie den aufgerufenen Methoden natürlich keinen catch (Exception)<\/b>-Zweig mehr zuzuweisen.<\/p>\n
public static void FehlerbehandlungOben() {\r\n     try {\r\n         FehlerbehandlungUnten();\r\n     }\r\n     catch (Exception e) {\r\n         Console.WriteLine(\"Es ist ein Fehler aufgetreten: {0}\", e.GetType().ToString());\r\n     }\r\n}\r\nprivate static void FehlerbehandlungUnten() {\r\n     try {\r\n         Console.WriteLine(\"Geben Sie den Dividend und den Divisor als ganze \r\n             Zahlen ein.\");\r\n         Console.WriteLine(\"Dividend:\");\r\n         decimal Dividend = Convert.ToDecimal(Console.ReadLine());\r\n         Console.WriteLine(\"Divisor:\");\r\n         decimal Divisor = Convert.ToDecimal(Console.ReadLine());\r\n         decimal Quotient = Dividend \/ Divisor;\r\n         Console.WriteLine(\"Der Quotient lautet: {0}\", Quotient);\r\n     }\r\n     catch (DivideByZeroException e) {\r\n         Console.WriteLine(\"Der Dividend darf nicht 0 sein.\");\r\n     }\r\n     Console.ReadLine();\r\n}<\/pre>\n
Listing 6: Fehlerbehandlung in untergeordneter und übergeordneter Methode<\/span><\/b><\/p>\n
Auf diese Weise können Sie übrigens die vorgeschriebene Reihenfolge bei der Abarbeitung der Ausnahmen in ihrer Hie-rarchie unterlaufen: Wenn Sie in der aufgerufenen Methode catch (Exception) <\/b>unterbringen und in der aufrufenden Methode catch (DivideByZeroException)<\/b>, beanstandet Visual Studio das nicht.<\/p>\n
Aufräumarbeiten nach Fehlern: der finally-Block<\/h2>\n
Grundsätzlich sind wir mit dem try<\/b>– und den catch<\/b>-Blöcken gut ausgestattet: Wir legen mit dem try<\/b>-Block fest, für welchen Code-Abschnitt wir auf Fehler reagieren möchten. Mit dem catch<\/b>-Block können wir verschiedene spezifische oder auch allgemeine Ausnahmen behandeln.<\/p>\n
Was aber, wenn wir nach Auftreten eines Fehlers die Methode verlassen möchten, in dieser Methode aber noch Aufräum-arbeiten durchzuführen sind? Unter VBA haben wir das beispielsweise wie folgt programmiert:<\/p>\n
Public Sub <\/span>Fehlerbehandlung()\r\n     On Error GoTo<\/span> Fehler\r\n     Debug.Print<\/span> 1 \/ 0\r\nRestarbeiten:\r\n     ''Restarbeiten\r\n     ''...\r\n     Exit Sub<\/span>\r\nFehler:\r\n     ''Fehlerbehandlung\r\n     ''...\r\n     GoTo Restarbeiten\r\nEnd Sub<\/span><\/pre>\n
Trat hier kein Fehler auf, wurden die Anweisungen vor der Sprungmarke Restarbeiten <\/b>durchgeführt, danach die hinter Restarbeiten <\/b>aufgeführten Anweisungen. Damit die hinter der Sprungmarke Fehler <\/b>aufgeführten Anweisungen für die Fehlerbehandlung nur im Fehlerfall aufgerufen werden, haben wir dort zuvor die Anweisung Exit Sub <\/b>eingefügt.<\/p>\n
Ist hingegen ein Fehler aufgetreten, erfolgte der über die On Error Goto …<\/b>-Anweisung angegebene Sprung zur Sprungmarke Fehler<\/b>. Nach Ausführen der dortigen Anweisungen sollte die Prozedur noch zu den Anweisungen unter Restarbeiten springen, bevor diese endet.<\/p>\n
Unter C# könnten wir die nach Auftreten des Fehlers auszuführenden Anweisungen einfach hinter dem letzten catch<\/b>-Block anhängen (siehe Listing 7). Die dort befindlichen Anweisungen werden dann vor dem Verlassen der Methode noch ausgeführt.<\/p>\n
public static void Restarbeiten() {\r\n     try {\r\n         Console.WriteLine(\"Geben Sie den Dividend und den Divisor als ganze Zahlen ein.\");\r\n         Console.WriteLine(\"Dividend:\");\r\n         decimal Dividend = Convert.ToDecimal(Console.ReadLine());\r\n         Console.WriteLine(\"Divisor:\");\r\n         decimal Divisor = Convert.ToDecimal(Console.ReadLine());\r\n         decimal Quotient = Dividend \/ Divisor;\r\n         Console.WriteLine(\"Der Quotient lautet: {0}\", Quotient);\r\n     }\r\n     catch (DivideByZeroException) {\r\n         Console.WriteLine(\"Der Dividend darf nicht 0 sein.\");\r\n     }\r\n     catch (Exception e) {\r\n         Console.WriteLine(\"Fehler: {0}\", e.GetBaseException().ToString());\r\n     }\r\n     \/\/Restarbeiten\r\n     Console.Write(\"Restarbeiten.\");\r\n     Console.ReadLine();\r\n}<\/pre>\n
Listing 7: Restarbeiten nach Auftreten eines Fehlers am Ende der Methode<\/span><\/b><\/p>\n
Was aber, wenn wir die Methode beim Auftreten eines Fehlers verlassen möchten, weil beispielsweise die Daten für die noch auszuführenden Anweisungen fehlen und dennoch Restarbeiten innerhalb der Methode nötig sind?<\/p>\n
In diesem Fall kommt die der finally<\/b>-Block einer Ausnahmebehandlung zum Zuge. Der Aufbau sieht dann grob so aus:<\/p>\n
try {\r\n     ...\r\n}\r\ncatch {\r\n     ...\r\n}\r\nfinally {\r\n     ...\r\n}\r\n...Abschließende Anweisungen<\/pre>\n
Die Anweisungen im try<\/b>-Block werden so lange ausgeführt, bis ein Fehler auftaucht. Der catch<\/b>-Block wird ausgelöst, sobald im try<\/b>-Block ein Fehler ausgelöst wurde (zumindest, wenn es sich um einen allgemeinen catch<\/b>-Block handelt).<\/p>\n
Der finally<\/b>-Block schließlich wird immer ausgelöst – also unabhängig davon, ob ein Fehler auftritt oder nicht.<\/p>\n
Was aber ist nun der Unterschied, ob ich Anweisungen in den finally<\/b>-Block schreibe oder diese einfach an den letzten catch<\/b>-Block anhänge? Ganz einfach: Wenn Sie im catch<\/b>-Block die Methode verlassen, weil – wie oben beispielhaft angeführt – durch den Fehler eine weitere Ausführung der Methode keinen Sinn macht, führt die Methode dennoch den Teil im finally<\/b>-Block aus, aber nicht mehr den im Anschluss an den letzten Block der Fehlerbehandlung.<\/p>\n
Ein Beispiel finden Sie in Listing 8. Geben Sie die Werte 1 <\/b>und 0 <\/b>für die beiden ReadLine<\/b>-Anweisungen ein, löst dies eine DivideByZeroException <\/b>aus. Dabei soll die Methode nach der Ausgabe von Der Dividend darf nicht 0 sein <\/b>mit der return<\/b>-Anweisung verlassen werden. Dies geschieht auch, allerdings erst, nachdem die Anweisungen des finally<\/b>-Blocks ausgeführt wurden.<\/p>\n
public static void RestarbeitenMitFinally() {\r\n     try {\r\n         Console.WriteLine(\"Geben Sie den Dividend und den Divisor als ganze Zahlen ein.\");\r\n         Console.WriteLine(\"Dividend:\");\r\n         decimal Dividend = Convert.ToDecimal(Console.ReadLine());\r\n         Console.WriteLine(\"Divisor:\");\r\n         decimal Divisor = Convert.ToDecimal(Console.ReadLine());\r\n         decimal Quotient = Dividend \/ Divisor;\r\n         Console.WriteLine(\"Der Quotient lautet: {0}\", Quotient);\r\n     }\r\n     catch (DivideByZeroException) {\r\n         Console.WriteLine(\"Der Dividend darf nicht 0 sein.\");\r\n         return;\r\n     }\r\n     catch (Exception e) {\r\n         Console.WriteLine(\"Fehler: {0}\", e.GetBaseException().ToString());\r\n     }\r\n     finally {\r\n         \/\/Restarbeiten\r\n         Console.Write(\"Restarbeiten (Finally).\");\r\n         Console.ReadLine();\r\n     }\r\n     \/\/Restarbeiten\r\n     Console.Write(\"Restarbeiten.\");\r\n     Console.ReadLine();\r\n}<\/pre>\n
Listing 8: Restarbeiten nach Auftreten eines Fehlers am Ende der Methode mit Finally<\/span><\/b><\/p>\n
Wenn Sie hingegen einen Fehler auslösen, indem Sie eine Zeichenkette statt einer Zahl eingeben, löst dies eine allgemeine Exception aus, für die der zweite catch<\/b>-Block eingerichtet wurde. Nach diesem wird die Methode nicht verlassen, also geschieht Folgendes: Zunächst werden die Anweisungen im finally<\/b>-Block ausgeführt und dann die Anweisungen hinter dem try…catch…finally<\/b>-Block.<\/p>\n
Fehler per Code auslösen<\/h2>\n
Unter VBA gab es die Möglichkeit, mit der Error<\/b>-Anweisung einen Fehler auszulösen. Die folgende Anweisung erzeugte dabei einen der eingebauten Fehler, wenn Sie die korrekte Fehlernummer angegeben haben – hier beispielsweise den Fehler Division durch Null <\/b>(siehe Bild 10):<\/p>\n
\"Erzeugen<\/p>\n
Bild 10: Erzeugen eines Fehlers unter VBA<\/span><\/b><\/p>\n
Error 11<\/pre>\n
Unter C# gibt es natürlich auch eine Möglichkeit, selbst Fehler auszulösen. Am einfachsten ist das, wenn Sie beim Auftreten einer behandelten Ausnahme doch noch die eingebaute Ausnahmebehandlung starten wollen. Dann fügen Sie innerhalb des catch<\/b>-Blocks einfach noch die Anweisung throw (e) <\/b>ein (siehe Listing 9).<\/p>\n
public static void ExceptionMitThrow() {\r\n     try {\r\n         ...\r\n         decimal Quotient = Dividend \/ Divisor;\r\n         Console.WriteLine(\"Der Quotient lautet: {0}\", Quotient);\r\n     }\r\n     catch (Exception e) {\r\n         Console.WriteLine(\"Es ist ein Fehler aufgetreten.\");\r\n         throw (e);\r\n     }\r\n}<\/pre>\n
Listing 9: Werfen des Fehlers nach der Fehlerbehandlung<\/span><\/b><\/p>\n
In der Ausführung sieht das so wie in Bild 11 aus. Der Fehler wird ausgelöst und innerhalb des catch<\/b>-Blocks behandelt, aber dort wird der Fehler erneut geworfen.<\/p>\n
\"Werfen<\/p>\n
Bild 11: Werfen des Fehlers trotz catch-Block<\/span><\/b><\/p>\n
Dieses Feature ist interessant, wenn Sie vor dem tatsächlichen Verarbeiten der Ausnahme mit den dafür vorgesehenen, eingebauten Mitteln noch benutzerdefinierte Schritte durchführen möchten.<\/p>\n
throw für benutzerdefinierte Fehler<\/h2>\n
Unter VBA konnten Sie, auch wenn dies den meisten VBA-Entwicklern nicht bekannt ist, benutzerdefinierte Fehler erzeugen. Dies gelingt auch unter C#. Hier müssen Sie allerdings zunächst eine benutzerdefinierte Exception<\/b>-Klasse definieren, die von der Klasse Exception<\/b> abgeleitet wird. Diese sieht im einfachsten Fall wie folgt aus:<\/p>\n
public class MeineException : Exception {\r\n} <\/pre>\n
Wenn Sie diese Exception<\/b>-Klasse nutzen wollen, erstellen Sie wie zuvor einen try…catch<\/b>-Block. Um den Fehler auszulösen, rufen Sie die throw<\/b>-Methode auf und übergeben dieser eine neue Instanz Ihrer benutzerdefinierten Exception<\/b>-Klasse als Parameter (siehe Listing 10). Dies liefert eine ähnliche Ausgabe, als wenn Sie eine der eingebauten Exceptions auslösen:<\/p>\n
public static void Exception_Benutzerdefiniert() {\r\n     Console.WriteLine(\"Jetzt kommt ein Fehler.\");\r\n     try {\r\n         throw new MeineException();\r\n     }\r\n     catch(Exception e) {\r\n         Console.WriteLine(\"MeineException wurde ausgelöst ({0}).\", e.GetBaseException().ToString());\r\n     }\r\n}<\/pre>\n
Listing 10: Auslösen eines benutzerdefinierten Fehlers<\/span><\/b><\/p>\n
Jetzt kommt ein Fehler.\r\nMeineException wurde ausgelöst (Fehlerbehandlung.MeineException: Eine Ausnahme vom Typ \"Fehlerbehandlung.MeineException\" wurde ausgelöst.\r\n    bei Fehlerbehandlung.Beispiele.Exception_Benutzerdefiniert() in C:\\Users\\....\\Fehlerbehandlung\\Fehlerbehandlung\\Beispiele.cs:Zeile 209.).\r\nAssembly: Fehlerbehandlung, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null<\/pre>\n
Eigenschaften des Exception-Objekts<\/h2>\n
Das Exception<\/b>-Objekt, das als Parameter eines catch<\/b>-Blocks ermittelt werden kann, liefert einige Eigenschaften, die Sie in der Fehlerbehandlung nutzen können:<\/p>\n
    \n
  • Data<\/b>: Liefert eine Collection von Schlüssel-Wert-Paaren mit weiteren Informationen zu Fehler.<\/li>\n
  • HelpLink<\/b>: Liefert einen Link zu einer Hilfedatei oder legt diesen fest.<\/li>\n
  • InnerException<\/b>: Ruft eine Exception-Instanz ab, welche die aktuelle Ausnahme ausgelöst hat.<\/li>\n
  • Message<\/b>: Liefert eine Meldung zur aktuellen Ausnahme.<\/li>\n
  • Source<\/b>: Name der Anwendung oder des Objekts, das die Ausnahme ausgelöst hat.<\/li>\n
  • StackTrace<\/b>: Liefert die Aufrufliste zum aktuellen Fehler.<\/li>\n
  • TargetSite<\/b>: Liefert die Methode, welche die Ausnahme ausgelöst hat.<\/li>\n<\/ul>\n
    Die Methode aus Listing 11 gibt alle Informationen für einen einfachen Fehler aus. Das Ergebnis ist nicht besonders ergiebig:<\/p>\n
    public static void Exception_Eigenschaften() {\r\n     try {\r\n         decimal Null = 0;\r\n         Console.WriteLine(\"Eins durch Null: {0}\", 1 \/ Null);\r\n     }\r\n     catch (Exception e) {\r\n         Console.WriteLine(\"Data:\\n{0}\", e.Data.Count);\r\n         Console.WriteLine(\"HelpLink:\\n{0}\", e.HelpLink);\r\n         Console.WriteLine(\"HResult:\\n{0}\", e.HResult);\r\n         Console.WriteLine(\"InnerException:\\n{0}\", e.InnerException);\r\n         Console.WriteLine(\"Message:\\n{0}\", e.Message);\r\n         Console.WriteLine(\"Source:\\n{0}\", e.Source);\r\n         Console.WriteLine(\"StackTrace:\\n{0}\", e.StackTrace);\r\n         Console.WriteLine(\"TargetSite:\\n{0}\", e.TargetSite);\r\n     }\r\n}<\/pre>\n
    Listing 11: Ausgabe der Fehlerinformationen des Exception-Objekts<\/span><\/b><\/p>\n
    Data <\/b>liefert ein Objekt des Typs System.Collections.ListDictionaryInternal<\/b>, wenn wir Data.Count <\/b>ausgeben lassen, erhalten wir jedoch den Wert 0<\/b>, was darauf hindeutet, dass hier keine Name-Wert-Paare mit zusätzlichen Informationen hinterlegt wurden.<\/p>\n
    Data <\/b>können Sie auch selbst füllen, zum Beispiel, um weitere Informationen zu einem benutzerdefiniert ausgelösten Fehler zu liefern.<\/p>\n
    Die folgende Methode erzeugt im try<\/b>-Block ein neues Exception<\/b>-Objekt und fügt zur Data<\/b>-Auflistung mit der Add<\/b>-Methode einen neuen Eintrag hinzu, dessen Name Zeitpunkt <\/b>lautet und dessen Wert über den Ausdruck DateTime.Now <\/b>mit Datum und Uhrzeit des Fehlers gefüllt wird. Danach lösen wir den Fehler mit der throw<\/b>-Anweisung aus.<\/p>\n
    Der catch<\/b>-Block greift das Exception<\/b>-Objekt mit der Variablen e <\/b>auf und gibt zunächst die Fehlermeldung aus der Eigenschaft Message <\/b>und dann den Wert des Elements Zeitpunkt <\/b>der Data<\/b>-Auflistung aus:<\/p>\n
    public static void DataImBenutzerdefiniertenFehler() {\r\n     try {\r\n         Exception e = new Exception();\r\n         e.Data.Add(\"Zeitpunkt\", DateTime.Now);\r\n         throw e;\r\n     }\r\n     catch (Exception e) {\r\n         Console.WriteLine(\"Fehler: {0}\", e.Message);\r\n         Console.WriteLine(\"Zeitpunkt: {0}\", \r\n             e.Data[\"Zeitpunkt\"]);\r\n     }\r\n}<\/pre>\n
    Dies ist das Ergebnis, das in der Konsole ausgegeben wird:<\/p>\n
    Fehler: Eine Ausnahme vom Typ \"System.Exception\" wurde ausgelöst.\r\nZeitpunkt: 06.06.2016 10:28:01<\/pre>\n
    Wenn Sie mehrere Informationen mit dem Data-Objekt übergeben möchten, können Sie diese natürlich auch in einer foreach-Schleife durchlaufen. Wie dies aussieht, sehen Sie in Listing 12.<\/p>\n
    public static void MehrDataImBenutzerdefiniertenFehler() {\r\n     try {\r\n         Exception e = new Exception();\r\n         e.Data.Add(\"Zeitpunkt\", DateTime.Now);\r\n         e.Data.Add(\"Ort\", \"Duisburg\");\r\n         e.Data.Add(\"Benutzer\", \"André Minhorst\");\r\n         throw e;\r\n     }\r\n     catch (Exception e) {\r\n         Console.WriteLine(\"Fehler: {0}\", e.Message);\r\n         if (e.Data.Count > 0) {\r\n             Console.WriteLine(\"Inhalt von Data:\");\r\n             foreach (DictionaryEntry de in e.Data)\r\n                 Console.WriteLine(\"{0}: {1}\", de.Key, de.Value);\r\n         }\r\n     }\r\n}<\/pre>\n
    Listing 12: Ausgabe des Data-Objekts einer Exception per foreach-Schleife<\/span><\/b><\/p>\n
    Die Methode fügt gleich drei verschiedene Name-Wert-Paare zur Data-Auflistung hinzu. Im catch-Zweig gibt die Methode wieder den Fehlertext aus. Danach prüft sie in einer if-Bedingung, ob das Data-Objekt überhaupt einen Eintrag enthält. Dies gelingt durch einen Vergleich der Eigenschaft Data.Count mit dem Wert 0. Liegen Einträge vor, startet eine foreach-Schleife, welche alle Elemente von e.Data, in diesem Fall mit dem Typ DictionaryEntry, durchläuft und jeweils mit der Variablen de referenziert. Innerhalb der Schleife gibt die Methode den Namen und den Wert des jeweiligen Eintrags aus.<\/p>\n
    Die Ausgabe sieht nun so aus:<\/p>\n
    Inhalt von Data:\r\nZeitpunkt: 06.06.2016 10:41:00\r\nOrt: Duisburg\r\nBenutzer: André Minhorst<\/pre>\n
    Eingebauten Fehler um Data anreichern<\/h2>\n
    Data<\/b>-Elemente können Sie nicht nur benutzerdefinierten Fehlern hinzufügen, sondern natürlich auch eingebauten Exceptions. Wie das gelingt, zeigt das Beispiel aus Listing 13. Hier rufen wir im try-Block der ersten Methode eine untergeordnete Methode auf. Diese erzeugt in ihrem try-Block einen Fehler durch das Teilen durch 0. Der Fehler wird erst im catch-Block der untergeordneten Methode behandelt, wo wir diesem drei Name-Wert-Paare für die Data-Collection hinzufügen. Damit wir diese in der aufrufenden Methode auswerten können, werfen wir den Fehler mit der throw-Methode erneut. Die aufrufende Methode führt dann ebenfalls den catch-Block aus und verarbeitet die Inhalte des Data-Objekts. Das Ergebnis sieht in diesem Falle ähnlich aus wie zuvor:<\/p>\n
    public static void DataAnreichern() {\r\n     try {\r\n         DataAnreichernSub();\r\n     }\r\n     catch (Exception e) {\r\n         Console.WriteLine(\"Fehler: {0}\", e.Message);\r\n         if (e.Data.Count > 0) {\r\n             Console.WriteLine(\"Inhalt von Data:\");\r\n             foreach (DictionaryEntry de in e.Data)\r\n                 Console.WriteLine(\"{0}: {1}\", de.Key, de.Value);\r\n         }\r\n     }\r\n}\r\nprivate static void DataAnreichernSub() {\r\n     try {\r\n         decimal Null = 0;\r\n         decimal EinsDurchNull = 1 \/ Null;\r\n     }\r\n     catch (Exception e) {\r\n         e.Data.Add(\"Zeitpunkt\", DateTime.Now);\r\n         e.Data.Add(\"Ort\", \"Duisburg\");\r\n         e.Data.Add(\"Benutzer\", \"André Minhorst\");\r\n         throw e;\r\n     }\r\n}<\/pre>\n
    Listing 13: Fehlerinformationen aus einer Sub-Methode anreichern<\/span><\/b><\/p>\n
    Fehler: Es wurde versucht, durch 0 (null) zu teilen.\r\nInhalt von Data:\r\nZeitpunkt: 06.06.2016 11:09:20\r\nOrt: Duisburg\r\nBenutzer: André Minhorst<\/pre>\n
    HelpLink und HResult<\/h2>\n
    HelpLink <\/b>liefert eine leere Zeichenkette, HResult<\/b> den Wert -2.147.352.558<\/b>. HResult<\/b> liefert eine Fehlernummer, wie Sie sie auch von VBA kennen. Wer kennt nicht die Fehlernummer 3022 <\/b>für das Verletzen einer Integritätsregel bei Hinzufügen oder Ändern eines Datensatzes?<\/p>\n
    Im Falle des hier ausgelösten Fehlers DivideByZeroException <\/b>liefert HResult <\/b>den Wert -2.147.352.558<\/b>, hexadezimal 80020012<\/b>. Unter VBA hätten Sie diesen Wert zur Identifizierung des Fehlers in einer Select Case<\/b>-Bedingung genutzt, unter C# ist dies nicht nötig – hier können wir jede Exception direkt über den Typ in einem eigenen catch<\/b>-Block verarbeiten.<\/p>\n
    InnerException<\/h2>\n
    InnerException <\/b>liefert für das einfache Beispiel von oben eine leere Zeichenkette. Das hat seinen Grund, denn die InnerException <\/b>bezeichnet eine Ausnahme, in deren Folge die aktuelle Ausnahme ausgelöst wurde. Ein Beispiel ist das Füllen einer Log-Datei mit den Informationen zu auftretenden Ausnahmen.<\/p>\n
    Nun kann es geschehen, dass diese Log-Datei nicht beschrieben werden kann – beispielsweise durch fehlende Berechtigungen, weil die Datei oder das Verzeichnis vorhanden ist et cetera. Dann löst dies eine weitere Ausnahme aus, die wir natürlich ebenfalls behandeln wollen, statt sie dem Benutzer als unbehandelte Ausnahme zu präsentieren.<\/p>\n
    Also packen wir wie in Listing 14 das try…catch<\/b>-Konstrukt, das unseren Fehler durch das Dividieren von 1 <\/b>durch 0 <\/b>behandeln soll, in einen weiteren try<\/b>-Block. Im inneren try<\/b>-Block befinden sich die Anweisungen, die den DivideByZero<\/b>-Fehler auslösen sollen.<\/p>\n
    public static void InnerException() {\r\n     try {\r\n         try {\r\n             decimal Null = 0;\r\n             decimal EinsDurchNull = 1 \/ Null;\r\n         }\r\n         catch (Exception e) {\r\n             if (File.Exists(\"c:<\/font>Logs<\/font>CSharplog.log\")== false) {\r\n                 throw new Exception(\"Log-Datei nicht gefunden\", e);\r\n             }\r\n         }\r\n     }\r\n     catch (Exception e) {\r\n         Console.WriteLine(\"Fehler: {0}\", e.Message);\r\n         Console.WriteLine(\"InnerException: {0}\", e.InnerException);\r\n     }\r\n}<\/pre>\n
    Listing 14: Beispiel für das InnerException-Objekt<\/span><\/b><\/p>\n
    Tritt nun die 1\/0-Exception auf, tritt der innere catch<\/b>-Block auf den Plan: Er prüft, ob die Datei vorhanden ist, und wirft anderenfalls eine neue Ausnahme. Dieser übergibt er als ersten Parameter den Text Log-Datei nicht gefunden <\/b>und als zweiten mit der Variablen e <\/b>einen Verweis auf die auslösende Exception.<\/p>\n
    Dies bewirkt wiederum, dass der catch<\/b>-Block des äußeren try…catch<\/b>-Konstrukts angesteuert wird. Dieser gibt zuerst die Meldung des Fehlers und als zweites den Wert der Variablen InnerException <\/b>in der Konsole aus:<\/p>\n
    Fehler: Log-Datei nicht gefunden\r\nInnerException: System.DivideByZeroException: Es wurde versucht, durch 0 (null) zu teilen.\r\n    bei System.Decimal.FCallDivide(Decimal& d1, Decimal& d2)\r\n    bei System.Decimal.op_Division(Decimal d1, Decimal d2)\r\n    bei Fehlerbehandlung.Beispiele.InnerException() in \r\n    C:\\...\\Fehlerbehandlung\\Beispiele.cs:Zeile 296.<\/pre>\n
    Fehlermeldung im Klartext<\/h2>\n
    Message <\/b>liefert die Fehlermeldung im Klartext, in diesem Fall Es wurde versucht, durch 0 (null) zu teilen.<\/b><\/p>\n
    Fehlerquelle<\/h2>\n
    Source <\/b>bringt in diesem Fall den Namen der Klasse, die den Fehler ausgelöst hat: mscorlib<\/b>.<\/p>\n
    Fehlerursprung verfolgen<\/h2>\n
    Manchmal wird ein Fehler aus einer untergeordneten Methode in einer übergeordneten Methode verarbeitet. Dann kann es hilfreich sein, den Weg hin zum Fehlerursprung zu verfolgen. Dabei hilft die Eigenschaft StackTrace <\/b>des Exception<\/b>-Objekts. In Listing 15 haben wir eine Fehlerbehandlung in einer Methode untergebracht, die eine weitere Methode aufruft, die dann schließlich die fehlerauslösende Methode nutzt.<\/p>\n
    public static void StackTraceBeispiel() {\r\n     try {\r\n         StackTraceSub();\r\n     }\r\n     catch(Exception e) {\r\n         Console.WriteLine(\"Stacktrace:\\n{0}\", e.StackTrace);\r\n     }\r\n}\r\nprivate static void StackTraceSub() {\r\n     StackTraceSub2();\r\n}\r\nprivate static void StackTraceSub2() {\r\n     decimal Null = 0;\r\n     decimal EinsDurchNull = 1 \/ Null;\r\n}<\/pre>\n
    Listing 15: Beispiel für die Ausgabe des StackTrace<\/span><\/b><\/p>\n
    Das Ergebnis der StackTrace<\/b>-Eigenschaft sieht dann wie folgt aus:<\/p>\n
    Stacktrace:\r\n    bei System.Decimal.FCallDivide(Decimal& d1, Decimal& d2)\r\n    bei System.Decimal.op_Division(Decimal d1, Decimal d2)\r\n    bei Fehlerbehandlung.Beispiele.StackTraceSub2() in \r\n        C:\\...\\Fehlerbehandlung\\Beispiele.cs:Zeile 322.\r\n    bei Fehlerbehandlung.Beispiele.StackTraceSub() in \r\n        C:\\...\\Fehlerbehandlung\\Beispiele.cs:Zeile 318.\r\n    bei Fehlerbehandlung.Beispiele.StackTraceBeispiel() in\r\n        C:\\...\\Fehlerbehandlung\\Beispiele.cs:Zeile 311.<\/pre>\n
    Die oberen beiden Zeilen liefern Informationen über die Elemente des .NET-Frame, die den Fehler auslösten, die unteren drei beschreiben den Weg über die drei Methoden bis zum Fehler – die zuletzt aufgerufenen Methoden landen weiter oben in der Liste.<\/p>\n
    Fehlerhafte Methode untersuchen<\/h2>\n
    TargetSite<\/b> liefert Informationen über die Methode, die den Fehler ausgelöst hat. Das Objekt enthält selbst einige Eigenschaften mit weiteren Details, die wir an dieser Stelle nicht weiter inspizieren wollen.<\/p>\n
    Klassenweise Exceptions<\/h2>\n
    Die Definition der verschiedenen Exceptions finden Sie übrigens über verschiedene Klassen des .NET-Frameworks verteilt. Das Basis-Objekt Exception<\/b>, von dem alle übrigen …Exception<\/b>-Objekte erben, befindet sich in der System<\/b>-Klasse, so wie auch einige andere wie das hier oft verwendete DivideByZero<\/b>-Objekt. Andere befinden sich in weiteren Klassen, zum Beispiel finden Sie FileNotFoundException <\/b>in der Klasse System.IO<\/b>.<\/p>\n
    Wenn Sie also einmal ein …Exception<\/b>-Objekt aus einem der Beispiele zu diesem Artikel eingeben möchten und dieses nicht per IntelliSense angeboten wird, liegt das möglicherweise daran, dass die Klasse, in der sich das Objekt befindet, noch nicht per using<\/b>-Direktive hinzugefügt wurde.<\/p>\n
    Zusammenfassung und Ausblick<\/h2>\n
    Dies war ein Überblick über die grundlegende Behandlung von Fehlern unter C# mit try<\/b>-, catch<\/b>– und finally<\/b>-Blöcken. Neben den Objekten und Eigenschaften, die Sie benötigen, um dem Benutzer statt unbehandelter Ausnahmen zumindest eine benutzerdefinierte Fehlermeldung zu liefern, haben Sie auch noch einige Eigenschaften kennen gelernt, die dem Entwickler bei der Fehleranalyse eine wichtige Hilfe sein können.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Nur wenige Access-Programmierer statten ihre Anwendungen mit einer ordentlichen Fehlerbehandlung aus. Für viele ist dies ein leidiges Thema. Die Fehlerbehandlung sorgt im Optimalfall sowohl unter VBA als auch unter C# dafür, dass eine Anwendung stabiler wird und nach dem Auftreten von Laufzeitfehlern nicht unerwartet reagiert oder sogar abstürzt. Während es unter VBA nur wenige Konstrukte gibt, um eine Fehlerbehandlung zu implementieren, bietet C# schon eine Menge mehr. Dieser Artikel liefert eine Einführung und zeigt, wie Sie die von VBA gewohnten Techniken unter C# einsetzen.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662016,66032016,44000001,44000025],"tags":[],"yst_prominent_words":[],"class_list":["post-55000037","post","type-post","status-publish","format-standard","hentry","category-662016","category-66032016","category-CGrundlagen","category-VBAProgrammierung"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts\/55000037","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/comments?post=55000037"}],"version-history":[{"count":0,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/posts\/55000037\/revisions"}],"wp:attachment":[{"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/media?parent=55000037"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/categories?post=55000037"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/tags?post=55000037"},{"taxonomy":"yst_prominent_words","embeddable":true,"href":"https:\/\/vbentwickler.de\/data\/wp\/v2\/yst_prominent_words?post=55000037"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}