7.2 Die Klassenhierarchie der Fehler

Eine Exception ist ein Objekt, welches direkt oder indirekt von java.lang.Throwable abgeleitet ist. Von dort aus verzweigt sich die Hierarchie der Fehlerarten nach java.lang.Exception und java.lang.Error. Die Klassen, die aus Error hervorgehen, sollen nicht weiterverfolgt werden. Es handelt sich hierbei um Fehler, die so schwer wiegend sind, dass sie zur Beendigung des Programms führen und vom Programmierer nicht weiter beachtet werden müssen und sollen. Throwable vererbt eine Reihe von nützlichen Methoden, die in der folgenden Grafik sichtbar sind. Sie fasst gleichzeitig die Vererbungsbeziehungen noch einmal zusammen.

Hier klicken, um das Bild zu Vergrößern

7.2.1 Die Exception-Hierarchie

Jede Benutzerausnahme wird von java.lang.Exception abgeleitet. Die Exceptions sind Fehler oder Ausnahmesituationen, die vom Programmierer behandelt werden sollen. Die Klasse Exceptions teilt sich dann nochmals in weitere Unterklassen beziehungsweise Unterhierarchien auf. Die folgende Grafik zeigt einige Unterklassen der Klasse Exception:

Hier klicken, um das Bild zu Vergrößern

7.2.2 Oberausnahmen fangen

Eine Konsequenz der Hierarchien ist, dass es ausreicht, einen Fehler der Oberklasse aufzufangen. Wenn zum Beispiel eine FileNotFoundException auftritt, dann ist diese Klasse von IOException abgeleitet, was heißt, FileNotFoundException ist eine Spezialisierung. Wenn wir alle IOException auffangen, behandeln wir damit auch gleichzeitig die FileNotFoundException mit.

Erinnern wir uns noch einmal an das Dateibeispiel. Dort haben wir eine FileNotFoundException und eine IOException einzeln behandelt. Dies lässt sich wie folgt zusammenfassen:

Listing 7.6 ReadFileWithRAFShort.java

import java.io.*;
public class ReadFileWithRAFShort
{
  public static void main( String args[] )
  {
    try
    {
      RandomAccessFile f = new RandomAccessFile( "c:/winnt/desktop.ini", "r" );
      
      for ( String line; (line=f.readLine()) != null; )
        System.out.println( line );
    }
    catch ( IOException e )
    {
      System.err.println( "Ein/Ausgabe-Probleme." );
    }
  }
}

Angst davor, dass wir den Fehlertyp später nicht mehr unterscheiden können, brauchen wir nicht zu haben, denn die an die catch-Anweisung gebundenen Variablen können wir mit instanceof weiter verfeinern. Doch aus Gründen der Übersichtlichkeit sollte diese Technik sparsam angewendet werden. Fehlerarten, die unterschiedlich behandelt werden müssen, verdienen immer getrennte catch-Klauseln. Das trifft zum Beispiel auf FileNotFoundException und IOException zu.

Hier klicken, um das Bild zu Vergrößern

7.2.3 Alles geht als Exception durch

Da Exception die Basisklasse aller Exceptions ist, ließe sich natürlich auch alles mit Exception abfangen. So könnte jemand auf die Idee kommen, aus

try {
  irgendwas Unartiges ...
}
catch ( IllegalAccessException e ) { ... }
catch ( InstantiationException e ) { ... }

eine Optimierung zu versuchen, die etwa so aussieht:

try {
  irgendwas Unartiges ...
}
catch ( Exception e ) { ... }

Da der Aufruf in den catch-Blöcken gleich aussieht, ließe sich alles in einer Routine zur Fehlerbehandlung ausführen. Doch dann muss die Oberklasse genommen werden - sozusagen der kleinste gemeinsame Nenner -, und dies ist die Klasse Exception. Doch was für andere Fehlertypen gut funktionieren mag, ist für catch(Exception) gefährlich. Denn so wird wirklich jeder Fehler aufgefangen und in der Ausnahmebehandlung bearbeitet. Taucht beispielsweise eine null-Referenz durch eine nicht initialisierte Variable mit Referenztyp auf, so würde auch dies fälschlicherweise behandelt.

Auch Nachfolgendes würde durch das Auffangen einer allgemeinen Exception abgefangen werden. Daher ist das Zusammenfassen zur Oberklasse Exception in der Regel keine gute Lösung.

Point p;
p.setX( 2 );    // Nicht initialisiert
int i = 0;
int x = 12/i;   // Division durch Null

Tritt eine Exception auf, so wird sie im Ausgabefenster rot angezeigt. Praktischerweise sind die Fehlermeldungen wie Links: ein Klick und Eclipse zeigt die Zeile an, die die Exception auslöste.

Hier klicken, um das Bild zu Vergrößern

7.2.4 Ausnahmen, die nicht aufgefangen werden müssen: RuntimeException

Einige Fehlerarten können potenziell an vielen Programmstellen auftreten, etwa eine Division durch Null oder ungültige Indexwerte beim Zugriff auf Array-Elemente. Treten solche Fehler beim Programmlauf auf, liegt in der Regel ein Denkfehler des Programmierers vor und das Programm sollte normalerweise nicht versuchen, die ausgelöste Ausnahme aufzufangen und zu behandeln. Daher wurde die Unterklasse RuntimeException eingeführt, die Fehler beschreibt, die vom Programmierer behandelt werden können, aber nicht müssen. Sie werden ausgelöst, wenn der Entwickler beispielsweise doch nicht die Division durch Null verhindert (ArithmeticException) oder die Indexgrenzen missachtet (IndexOutOfBoundsExceptions).

Hier klicken, um das Bild zu Vergrößern

7.2.5 Harte Fehler: Error

Fehler, die von der Klasse java.lang.Error abgeleitet sind, stellen Fehler dar, die mit der JVM in Verbindung stehen. Anders dagegen die Klassen, die von Exceptions abgeleitet sind - sie stehen für eigene Programmfehler. Bespiele dafür sind AssertionError, AWTError, CoderMalfunctionError, FactoryConfigurationError, LinkageError, ThreadDeath, TransformerFactoryConfigurationError, VirtualMachineError (mit den Unterklasen OutOfMemoryError, StackOverflowError, UnknownError). Im Fall von ThreadDeath lässt sich ableiten, dass nicht alle Error-Klassen auf »Error« enden.

Da die Fehler »abnormales« Verhalten anzeigen, müssen sie auch nicht mit einem try/catch-Block aufgefangen werden. Allerdings ist es möglich, die Fehler mit einem try/catch aufzufangen, da Error-Klassen Unterklassen von Throwable sind und sich daher genauso verhalten. In sofern ist ein Auffangen legitim und auch ein finally ist korrekt. Ob das Auffangen sinnvoll ist, ist eine andere Frage, denn wenn die JVM einen Fehler anzeigt, bleibt offen, wie darauf sinnvoll zu reagieren ist. Was sollten wir bei einer LinkageError machen? Einen OutOfMemoryError in bestimmten Programmteilen aufzufangen kann jedoch von Vorteil sein. Eigene Unterklassen von Error sollten keine Anwendung finden.