Fehlermeldungen
Nutzen von Exceptions
Ich habe in einem der vorhergehenden Beispiele(EConvertError) ja schon einmal kurz angedeutet, wie man Exceptions vermeidet. Nun stellt sich die Frage, für was es überhaupt Exceptions gibt, wenn man sie eh vermeiden muss. Das Konzept der Exceptions existiert in vielen Programmiersprachen und fußt auf der objektorientierten Programmierung(OOP). Bevor es Exceptions gab, hat man im Wesentlichen mit zwei Systemen zur Fehlerbehandlung gearbeitet: Fehlercodes und Fehlerreportfunktionen. In der WinAPI, also der Funktionssammlung von Windows, welche nun zunehmend vom .NET-Framework(welches Exceptions benutzt) ersetzt werden soll, kommt man noch mit beiden Typen in Kontakt.
Fehlercodes
Wird eine Funktion ausgeführt, gibt sie einen Fehlercode(meist einen Integer) zurück, der angibt, ob die Funktion erfolgreich ausgeführt werden konnte(meist ist dann der Fehlercode 0) oder nicht. In letzterem Fall spezifiziert dann der Fehlercode die Art des Fehlers. Speziell dafür definierte Fehlerkonstanten machen dann den Code lesbarer. Das ganze hat allerdings einen Nachteil: Werden Funktionen von Funktionen benutzt, muss der Fehlercode immer „von Hand“ angepasst bzw. durchgereicht werden. Und da, fast jede Funktion ihre eigenen Fehlercodes hat, kann das zu einem riesigen Fehlercodebrei werden, was der Übersicht nicht gerade förderlich ist…
Fehlerreportingfunktionen
Eine Art „Übergangslösung“, wenn man das denn eine „Lösung“ nennen darf, sind die Funktionen vom Typ „RaiseLastOSError“. Tritt ein Fehler in einer Funktion auf, die dieses Konzept verfolgt, so merkt sich Windows diesen Fehler intern. Weiter passiert erstmal nichts. Die Funktion liefert dann nur noch zurück, ob sie erfolgreich ausgeführt wurde, oder nicht(z.B. über einen Rückgabewert vom Typ Boolean). In letzterem Fall kann dann der Programmierer an einer geeigneten Stelle RaiseLastOSError(bzw. früher: RaiseLastWin32Error) aufrufen und dem Anwender wird die Fehlermeldung präsentiert.
Exceptions
Mit der OOP kam dann schließlich ein Umdenken in der Programmierung. Wurden bisher Funktionssammlungen programmiert und diese genutzt(prozedurale Programmierung), so werden nun voneinander unabhängige Programmbausteine(so genannte Klassen; Beispiele: Buttons, Memos…) entwickelt. Diese sind nun in unterschiedlichen Schichten angeordnet(eine untere Schicht z.B. kümmert sich nur um die Daten und ausschließlich die oberste Schicht kommuniziert mit dem User). Je nach Komplexität und Art der Anwendung kann es mehr oder weniger dieser Schichten geben. Problematisch wird es nun, wenn ein Fehler in der untersten Schicht auftritt. Da nur die oberste Schicht mit dem Benutzer kommunizieren darf und aber gleichzeitig die mittleren Schichten im Fehlerfall wissen müssen, was sie zu tun haben(kontrollierter Abbruch einer Aktion), muss die Information, dass ein Fehler(und natürlich auch welcher) ganz unten aufgetaucht ist durch alle Schichten irgendwie nach oben wandern. Teilweise werden dabei auch noch unterschiedliche Informationen gebraucht.
Um den ganzen Fehlerbehandlungsprozess in den Griff zu bekommen, gibt es nun Exceptions. Eine Exception ist aus OOP-Sicht nichts anderes, als eine Klasse, die durch einen speziellen Mechanismus das Durchreichen der Fehlermeldung vereinfacht.
Eine Exception kann unterschiedliche Informationen enthalten und lässt sich daher mit einem Paket vergleichen. Tritt irgendwo ein Fehler auf, wird ein Paket(Exception) erstellt. Diese wird nun automatisch durch die einzelnen Schichten durchgereicht. Jede Schicht kann sich das Paket angucken, etwas rausnehmen, etwas reintun oder das Paket sogar für angekommen erklären(und damit auch nicht mehr weitergeben). So hat dann jede Schicht alle Infos die sie braucht und kann flexibel darauf reagieren. Dabei werden alle weiteren Aktionen abgebrochen, bis die Exception behandelt ist.
Dabei muss eine Exception nicht zwangsweise ein Fehler sein. Wie oben schon erwähnt ist eine Exception eine Art „erweiterter Rückgabewert“, der dem Programmierer die Möglichkeit gibt, Informationen (zu Ausnahmesituationen) aus unteren Schichten bis dorthin durchzureichen, wo sie gebraucht werden. Meistens handelt es sich dann um einen „Fehler“, aber eben nicht immer. Insbesondere bei den Indy-Komponenten führt dies bei manchen Usern von Zeit zu Zeit zu Verwirrung(EIdConnClosedGracefully)…
Wenn man also die Möglichkeit hat, Exceptions zu vermeiden, sollte man das natürlich tun, denn dann spart man sich(bzw. dem Programm) die ganze Paketversendearbeit. Ein Beispiel hierfür habe ich oben ja schon genannt. Manchmal braucht man aber genauere Informationen bzw. manchmal bietet sich gar keine Möglichkeit die Exception zu verhindern. Und genau für solche Fälle gibt es Exceptions. Wie man nun damit umgeht, sehen wir im nächsten Kapitel…