Exceptions

Tritt bei der Programmausführung ein Fehler auf, so „wirft"die Java – VM eine „Exception", also eine Ausnahme. Eine Exception führt in der Regel dazu, dass ein Programm abgebrochen und an der Konsole eine Fehlermeldung ausgegeben wird. Der Programmierer kann aber auch das Auftreten von Exceptions antizipieren und geeignete Fehlerbehandlungsroutinen vorsehen. Dazu dient das try – catch – finally Konstrukt:

Integer.parseInt(..) ist risikobehafteter Code, der eine Exception wirft, wenn die übergebene Zeichenkette nicht als Zahl erkannt werden kann. Wir möchten hier, dass das Programm nicht abgebrochen wird, sondern versucht wird, die darauf folgenden Werte zu parsen. Daher fangen wir die Exception im catch – Block ab und geben eine Fehlermeldung aus. Der finally – Block dient hier nur der Demonstration.

Beim try – catch - finally kann sowohl der catch als auch der finally – Block weggelassen werden. Fehlt der catch – Block, so wird die Exception „geworfen", aber vorher noch der finally – Teilausgeführt.

Welche Methoden der Java – Api Exceptions werfen, können Sie in der Dokumentation erkennen.

Exceptions selber sind Klassen, die von java.lang.Throwable abgeleitet wind. Die Klassenhierarchie ist umfangreich, ihr liegt das Bestreben zugrunde, für jeden möglichen Fehler eine eigene Klasse zu schaffen. Grundsätzlich lassen sich die Klassen wie folgt gliedern:

Errors (java.lang.Error und Kindsklassen) stehen für irreparable Fehler, die aus der VM selbst resultieren. Typischer Repräsentantist der java.lang.OutOfMemory Error, der auftritt, wenn die VM keine Speicher mehr zur Verfügung hat. Errors müssen nicht behandelt werden, da hier meist ohnehin nichts zu machen ist.

Java.lang.Exception und Subklassen sind Fehler, die unter voraussehbaren Umständen wie beispielsweise bestimmten Parametern oder falschen Eingaben auftreten werden. Im allgemeinen ist es sinnvoll, auf diesen Fall vorbereitet zu sein. Daher müssen sie in Java behandelt werden. Typischer Vertreter der Gruppe ist die java.io.IOException, die bei Dateioperationen geworfen werden kann.

In machen Fällen ist es nicht sinnvoll, das relative aufwändige Exception-Handling zu programmieren. Wenn zum Beispielbeim Zugriff auf ein Array ein negativer Index angegeben wird, so führt das natürlich zu einem Fehler, der in einer java.lang.ArrayIndexOutOfBoundsExcepton resultieret. Allerdings lässt sich im Vorfeld relativ einfach klären, ob ein Array - Index im gültigen Bereich liegt. Java lässt hier dem Programmierer die Wahl, ob erlieber im Vorfeld den Array – Index checkt oder das Exception-Handling durchführt. Daher müssen diese sogenannten RuntimeException (abgeleitet von java.lang.RuntimeException) wie die ArrayIndexOutOfBoundsException nicht behandelt werden. Es ist abermöglich, sie wie normale Exceptions zu behandeln.

Exceptions müssen nicht dort behandelt werden, wo sie entstehen. Manchmal weiss eine übergeordnete Methode besser, welches Verhalten im Fall eines bestimmten Fehler sinnvoll ist. In diesem Fall kann eine Exception auch „geworfen" werden:

Das Beispiel zeigt, wie die Exception, die in errorHere() entsteht, mit „throw" geworfen wird. Diese Möglichkeit muss mit „throws" in der Methodensignatur deklariert werden. Der aufrufende Konstruktor behandelt die Exception in der bekannten Weise, packt wie in eine RuntimeException und wirft sie weiter. Das ist natürlich kein sinnvolles Verhalten, zeigt aber, dass eine RuntimeException nicht deklariert werden muss. Die Exception landet dann bei der VM, die sie and der Konsole ausgibt und das Programm beendet. Beachten Sie den Stacktrace, (die Ausgabe der Exception an der Konsole), der genau Auskunft gibt, welche Ausnahmen an welcher Stelle aufgetreten ist.