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. Von Throwable werden eine Reihe von nützlichen Methoden vererbt, die in der folgenden Grafik sichtbar sind. Sie fasst gleichzeitig die Vererbungsbeziehungen noch einmal zusammen.

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.

7.2.2 Ober-Ausnahmen 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 Datei-Beispiel. Dort haben wir ein FileNotFoundException und eine IOException einzeln behandelt. Das 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;
      f = new RandomAccessFile( "c:/winnt/desktop.ini", "r" );

      String line;

      while ( (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 der 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.

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 das fälschlicherweise behandelt.

Auch Folgendes 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

7.2.4 Ausnahmen, die nicht gefangen 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).