Grundproblematik bei Fehlersituationen

Transkript

1 Name Klasse Datum 1 Grundproblematik bei Fehlersituationen Fehler können in vielen Situationen passieren. Fehlerhafte Eingaben, Files sind nicht mehr dort, wo sie erwartet werden, der Server ist plötzlich nicht mehr erreichbar usw. Der Aufrufer eines Unterprogramms muss in solch einer Situation informiert werden. Dies wird üblicherweise mit Hilfe des Rückgabewertes erledigt. Im nebenstehenden Code berechnet eine Methode einen Prozentwert auf Basis der beiden Parameter. Hierbei kann eine Division durch 0 erfolgen, welche wir vorher abprüfen. Wenn die 0 im Nenner auftreten würde, so können wir die Berechnung aussetzen und eine Fehlermeldung an den Aufrufer zurückschicken. Dies Funktioniert soweit ganz gut, sofern wir den Rückgabewert der Methode nur für Ausgaben benötigen. Sehen wir uns aber mal den folgenden Code an: Hier muss die Methode eine double Wert zurückgeben. Jeder Wert könnte aber aus einer korrekten Rechnung entstehen. Es gibt also keinen double Wert, der für eine Fehlererkennung verwendet werden könnte. Die 0, wie es hier im Code eingetragen ist wäre somit falsch! Bevor wir uns nun ansehen, wie die Lösung dieses Problems sein könnte, sehen wir uns noch eine zweite Situation an, welche mit einem speziellen Fehlerrückgabewert nicht gelöst werden kann. Hierzu erstellen wir einen Konstruktor mit einem Parameter. Wenn dieser jedoch nicht den Erwartungen entspricht, müssten wir hier ebenfalls an den Aufrufer eine Fehlernachricht senden. ANPR_Exceptions_v01.docx Seite 1

2 Ein Konstruktor gibt aber immer nur das erzeugte automatisch Objekt zurück ohne irgendein return Statement. Das heißt, wir haben hier ebenfalls keine Möglichkeit die Fehlersituation an den Aufrufenden zu melden. 2 Die Lösung ein eigener Informationskanal Das Hauptproblem ist eigentlich, dass wir immer nur einen Rückgabewert formulieren können. Könnten wir zwei Rückgabewerte weiterreichen, so wären einer für die Fehlermeldung und einer für das Verarbeitungsergebnis nutzbar. Die tatsächliche Lösung ist in der Tat ein ähnliches Konzept. Es gibt einen weiteren Kanal für die Meldung von Fehlern: Diese Fehler werden Ausnahmefehler oder Exceptions genannt. Sie werden nicht einfach zurückgegeben, sondern sie werden geworfen. Wir werden uns gleich ansehen, warum man einen solch merkwürdigen Namen gegeben hat. Warum macht man das eigentlich so umständlich? Wieso kann eine Methode nicht einfach zwei Rückgabewerte haben? Antwort: Prinzipiell wäre dies auch möglich. Die Einführung eines eigenen Informationskanals für Exceptions hat aber noch ein paar Vorteile. Zum einen wird die gesamte Verarbeitung unterbrochen da ja ein Fehler aufgetreten ist und Java somit davon ausgeht, dass die weitere Verarbeitung keinen Sinn mehr macht. Weiterhin können die Fehler innerhalb der Aufrufhierarchie sehr einfach weitergegeben werden. Dieses Konzept wird in den nächsten Kapiteln näher erklärt. 3 Der Weg einer Exception Java kennt von Haus aus viele Exceptions (also Ausnahmefehler) welche immer dann auftreten, wenn der ordentliche Ablauf des Programms nicht mehr gewährleistet werden kann. Beispielhalft sei hier die Null- PointerException genannt, welche immer dann auftritt wenn wir in einer Variablen auf eine Objektmethode oder Objekteigenschaft zugreifen wollen, die einen NULL Wert aufweist. Die Standardexceptions haben ein paar praktische Funktionalitäten eingebaut. Sie können bspw. den Stacktrace als Fehlermeldung in der Konsole ausgeben ( printstacktrace() ). Was ist eigentlich der Stack? Antwort: Der Stack ist eigentlich eine Speicherstruktur (Stapel- oder Kellerspeicher). Im Zusammenhang mit Exceptions meint man damit primär die Aufrufstruktur (welche ja auch im Speicher existiert) unserer Programme. Wenn also die main Methode eine weitere Methode (bspw. checkage() ) aufruft und diese wiederum Integer.parseInt(), dann befinden sich im Stack genau diese drei Methoden als Stapel übereinander. Der Stacktrace ist wiederum die Ausgabe dieser Hierarchie. Seite 2

3 Exceptions Sehen wir uns nun mal ein Programm an, welches eine Exception erzeugen könnte und was sie mit unserem Programm machen würde: Es gibt im Wesentlichen zwei wunde Punkte in diesem Programm. Der erste wäre die Eingabe eines Strings, der nicht in eine Zahl umgewandelt werden könnte und somit eine NumberFormatException auftreten würde. Das zweite Problem wäre ein Abbruch der JOptionPane, was in die Variable seingabealter einen null Wert zur Folge hätte. Dadurch würde der Befehl seingeabealter.equals("nn") zu einer Null- PointerException führen. Gehen wir mal von der Eingabe abcde aus, was die unten stehende NumberFormatException auf den Bildschirm zaubert: Das System würde also automatisch einen Stacktrace auf der Konsole ausgeben. Weiterhin würde die Programmverarbeitung sofort stoppen. Der Fehler wird also einfach durchgereicht, bis er in der JVM (Java Virtual Machine) auftrifft. Dort wird standardmäßig der Stacktrace ausgegeben. 4 Aufhalten der Fehler Da eine Exception erstmal die Abarbeitung unterbricht, das aber im Regelfall nicht vom Programmierer gewünscht ist, müssen wir nun etwas tun! Exceptions können wir uns wie eine Art Rohrpost vorstellen, welche vom Entstehungsort bis zur JVM laufen. Wenn sie auf diesem Weg niemand in die Hand nimmt (bzw. auffängt ), dann wird sie das Ziel erreichen und das Programm wird beendet. Insofern müssen wir nun versuchen, diese Exception zu fangen. Hierzu öffnen wir einen gesicherten Bereich mit dem Schlüsselwort try. Die geschweiften Klam- Seite 3

4 mern markieren diesen Bereich. Anschließend folgt catch und in Klammern die Art der Fehler, welche aufgefangen werden sollen. Wenn alle Typen von Exceptions gefangen werden sollen, schreibt man hier einfach Exception e rein also eine beliebige Exception, welche dann in der Variablen e landet. Danach folgt die Fehlerbehandlung (in unserem Fall wird lediglich eine Ausgabe gemacht). Nun wird der Code ganz normal weitergeführt die Methode wird also nicht abgebrochen. Ich kann die Exception aber auch eine Ebene tiefer im Stack abfangen. Im rechten Bild wird lediglich der Aufruf checkage überwacht. Eventuelle Exceptions dort werden ja wieder weitergereicht und können somit auch hier gefangen werden. Die Ausgabe der Fehlermeldung erfolgt wiederum im catch Block. 5 Selektives Auffangen Ein Nachteil unseres Codes ist nun, dass wir zwischen den verschiedenen Fehlerarten nicht unterscheiden können. Der catch Block fängt ja alle Fehler auf und unterscheidet somit nicht zwischen unseren beiden möglichen Exceptions, der NullPointerException und der NumberFormatException. Aber auch hier ist eine Lösung parat. Wir können den catch Block kaskadieren. Hierzu schreiben wir einfach mehrere catch Blöcke untereinander. Wir beginnen mit dem catch Block der NumberFormatException, anschließend der catch Block für die NullPointerException. Da keine weiteren Exceptions auftreten können, sind keine weiteren Blöcke notwendig. Wenn ich aber einen Exceptiontyp vergessen würde, dann würde dieser auch wieder bis zur JVM durchgereicht werden. Da Exceptions auch Hierarchien unterliegen, sollten die Exception immer von der speziellen hin zur allgemeinen Exception abgefangen werden. Im Extremfall fängt der letzte catch Block eine Exception, was also die allgemeinste Exception wäre. 6 Eigene Exceptions Ja, man kann auch eigene Exceptions realisieren. Dies wird häufig dann gemacht, wenn man ein ausgefeiltes Errorhandling mit automatischem Logging und ähnlichen Spielereien realisieren muss. Hierzu muss man seine Exception immer von der Exception Klasse ableiten. Sehen wir uns mal einen Code für eine eigene Exception an. Wir behandeln unsere Exceptions wie ganz normale Klassen. Sie haben einen Konstruktor und beliebig viele Methoden. Üblicherweise werden alle notwendigen Informationen gleich über den Konstruktor übergeben, damit das Erzeugen unserer Exception Seite 4

5 Exceptions möglichst einfach in einer Zeile durchgeführt werden kann. In unserem Beispiel implementieren wir einfach eine individuelle Nachricht, welche später ausgelesen werden kann. So, nun müssen wir diese Exception nur noch erzeugen (bzw. da sie ja gefangen werden kann, werfen wir sie). Hierzu bauen wir diesen Code in unsere checkage Methode ein: Wir erzeugen an den entsprechenden Stellen also unsere Exception und platzieren eine individuelle Nachricht. Danach werfen wir die Exception mit throw, so dass der Aufrufende sie wiederum fangen kann. Der Code der Methode wird an dieser Stelle natürlich abgebrochen. Der Aufrufende muss jetzt nur noch auf MyException hören und kann die Information auswerten. Wir erinnern uns: im catch Block spezifizieren wir die Exception, welche wir auffangen möchten. Das geschieht über den Klassennamen der Exception (in unserem Fall MyException ). Danach folgt der Variablenname (in unserem Fall habe ich das Ding myexception getauft). Das ist also nichts Weiteres als eine Deklaration einer lokalen Variablen, so wie wir das auch schon von der Parameterliste unserer Methoden kennen. Also können wir auf innerhalb der geschweiften Klammern einfach darauf zugreifen. 7 Finally schnell noch aufräumen Die oben beschriebene Methodik hat noch einen kleinen Haken. Wenn wir bspw. im try Block ein File öffnen wollen, dann können wir nicht einfach eine neue Exception werfen, da wir das File ja vorher noch schließen müssen. Hier kommt das finally ins Spiel. Sehen wir uns dazu mal den folgenden Code an. Hier fangen wir wie gehabt die Exceptions und werfen unsere eigenen. Wenn wir im Code bspw. die Null- PointerException provozieren, dann sehen wir auf der Konsole trotzdem noch die Nachricht Test beendet.. Dies bedeutet, dass der finally Block noch bearbeitet wird, bevor unsere Exception erzeugt und geworfen wird, was ja die Ausführung der Methode beendet. Weiterhin ist zu beachten, dass finally auch dann verarbeitet wird, wenn keine Exception gefangen wurde. Dies ist also der richtige Ort um aufzuräumen, also noch Files oder Datenbankverbindungen zu schließen. Seite 5

6 8 Lizenz Diese(s) Werk bzw. Inhalt von Maik Aicher ( steht unter einer Creative Commons Namensnennung - Nicht-kommerziell - Weitergabe unter gleichen Bedingungen 3.0 Unported Lizenz. Seite 6