8.8    Besonderheiten bei der Ausnahmebehandlung * 

Bei der Ausnahmebehandlung gibt es ein paar Überraschungen, die in den folgenden vier Unterabschnitten gesondert vorgestellt werden.

 

8.8.1    Rückgabewerte bei ausgelösten Ausnahmen 

Verspricht die Methode eine Rückgabe, so prüft der Compiler, ob jeder Programmfluss zu einem Rückgabewert führt. Doch die Aussage »Jede Methode mit einem Ergebnistyp ungleich void muss eine return-Anweisung besitzen« müssen wir etwas relativieren. Nur in einem speziellen Fall muss die Methode keine return-Anweisung besitzen, nämlich genau dann, wenn vor dem Ende der Methode eine throw-Anweisung die Abarbeitung beendet:

class Windows10KeyGenerator {

  public String generateKey() {

    throw new UnsupportedOperationException();

  }

}

Ein Blick auf generateKey() verrät, dass trotz eines angekündigten Rückgabewerts keine return-Anweisung im Rumpf steht. Die Abarbeitung wird vor dem Rücksprung durch eine Exception abgebrochen. Kann der Compiler sehen, dass eine Methode eine Ausnahme auslöst und die return-Anweisung nicht erreichbar ist, dann ist alles hinter dem throw nicht erreichbar und es dürfen keine weiteren Anweisungen folgen.

generateKey() muss diese Exception nicht mit throws ankündigen, da UnsupportedOperationException eine RuntimeException ist.

 

8.8.2    Ausnahmen und Rückgaben verschwinden – das Duo return und finally 

Ein Phänomen in der Ausnahmebehandlung von Java ist eine return-Anweisung innerhalb eines finally-Blocks. Zunächst einmal »überschreibt« ein return im finally-Block den Rückgabewert eines return im try-Block:

static String getIsbn() {

  try {

    return "3821829877";

  }

  finally {

    return "";

  }

}

Der Aufrufer empfängt immer einen leeren String.

Interessant ist auch folgendes Programm:

public static int a() {

  while ( true ) {

    try {

      return 0;

    }

    finally {

      break;

    }

  }



  return 1;

}

Die Ausgabe auf der Konsole ist 1. Das break im finally lässt die Laufzeitumgebung aus der Schleife austreten und den Rückgabewert ignorieren.

Ein weiteres Kuriosum sind Ausnahmen. Die Laufzeitumgebung gibt bei einer return-Anweisung im finally-Block eine im try-Block ausgelöste Ausnahme nicht zum Aufrufer weiter, sondern bietet einfach die Rückgabe an.

Die folgende Methode löst zum Beispiel eine RuntimeException aus, die aber der Aufrufer der Methode nie sieht:

static void hillaryVsDonald() {

  try {

    throw new RuntimeException();

  }

  finally {

    return;

  }

}

Entfernen wir die Zeile mit dem return, ist das Verhalten der Laufzeitumgebung so wie erwartet.

  Der Java-Compiler von Eclipse markiert die Diskrepanz und zeigt eine Warnung an (»finally block does not complete normally«). Mit der Annotation @SuppressWarnings("finally") schalten wir diesen Hinweis ab.

 

8.8.3    throws bei überschriebenen Methoden 

Beim Überschreiben von Methoden gibt es eine wichtige Regel: Überschriebene Methoden in einer Unterklasse dürfen nicht mehr Ausnahmen auslösen, als schon beim throws-Teil der Oberklasse aufgeführt sind. Da das gegen das Substitutionsprinzip verstieße, kann eine Methode der Unterklasse nur

• dieselben Ausnahmen wie die Oberklasse auslösen,

• Ausnahmen spezialisieren oder

• weglassen.

Dazu sehen wir hier ein konstruiertes Beispiel für die beiden letzten Fälle:

Listing 8.31    src/main/java/com/tutego/insel/exception/SubRandomAccessFile.java, Ausschnitt

public class SubRandomAccessFile extends RandomAccessFile {

  public SubRandomAccessFile( File file, String mode ) throws FileNotFoundException {

    super( file, mode );

  }

  @Override

  public long length() {

    try {

      return super.length();

    }

    catch ( IOException e ) {

      return 0;

    }

  }

  @Override

  public void write( int b ) throws ProtocolException {

    try {

      super.write( b );

    }

    catch ( IOException e ) {

      throw new ProtocolException();

    } 

  }

 

  @Override

  public void close() {

  }

}

Die Methoden length(), write(…) und close() lösen in RandomAccessFile eine IOException aus. Unsere Unterklasse SubRandomAccessFile überschreibt length() und lässt die Ausnahme in der Signatur weg. Das hat in der Nutzung einige Folgen, denn wenn wir die Klasse als SubRandomAccessFile der Art

SubRandomAccessFile raf = ...

raf.length();

verwenden, muss bei length() keine Ausnahme mehr abgefangen werden – und darf auch gar nicht abgefangen werden, weil ein try-catch auf eine IOException zu einem Compilerfehler führt.

Umgekehrt: Ist raf vom Typ der Basisklasse RandomAccessFile, muss die Ausnahme auf jeden Fall abgefangen werden:

RandomAccessFile raf = ...;

try {

  raf.length();

}

catch ( IOException e ) { }

Das zeigt die Schwierigkeit, bei überschriebenen Methoden die Ausnahmen wegzulassen.

Bei der Methode write(…) führt throws den Ausnahmetyp ProtocolException als Unterklasse von IOException auf. Natürlich reicht es nicht aus, in write(…) einfach super.write(…) stehen zu lassen (was nur eine allgemeinere IOException auslösen würde, aber nicht die versprochene speziellere ProtocolException). Daher fangen wir im Rumpf der Methode das super.write(…) ab und erzeugen die speziellere ProtocolException.

public SubRandomAccessFile( File file, String mode ) {

  try {

    super( file, mode );

  } catch ( Exception e ) { }

}

 

8.8.4    Nicht erreichbare catch-Klauseln 

Löst in einem try-Block eine Anweisung eine Ausnahme aus und gibt es dafür eine catch-Klausel, so heißt die catch-Klausel erreichbar. Zusätzlich darf vor dieser catch-Klausel natürlich kein anderes catch stehen, das diese Ausnahme mit abfängt. Wenn wir zum Beispiel catch(Exception e) als erstes Auffangbecken bereitstellen, behandelt das natürlich alle Ausnahmen. Die Konsequenz daraus: catch-Klauseln müssen immer von den speziellen zu den allgemeinen Ausnahmearten sortiert werden (alles andere würde der Compiler auch verhindern).

Wenn wir ein Objekt RandomAccessFile aufbauen und anschließend readLine() verwenden, so muss eine FileNotFoundException vom Konstruktor und eine IOException von readLine() abgefangen werden. Da eine FileNotFoundException eine Spezialisierung ist, also eine Unterklasse von IOException, würde ein catch(IOException e) schon reichen. Steht im Quellcode folglich der catch für die FileNotFoundException dahinter, wird der Teil nie ausgeführt werden können, und der Compiler merkt das zu Recht an.

Übertriebene throws-Klauseln

Eine Methode compiliert, auch wenn sie zu viele oder zu allgemeine Ausnahmen in ihrer throws-Klausel angibt:

Listing 8.32    src/main/java/com/tutego/insel/exception/TooManyExceptions.java, openFile()

void openFile() throws FileNotFoundException,

                       IOException,

                       InterruptedException {

  try ( RandomAccessFile r = new RandomAccessFile( "", "" ) ) { }

}

Unsere Methode openFile() ruft den Konstruktor von RandomAccessFile auf, was bekannterweise zu einer FileNotFoundException führen kann. openFile() jedoch gibt neben FileNotFoundException noch die allgemeinere Oberklasse IOException an und meldet mit InterruptedException noch eine geprüfte Ausnahme, die der Rumpf überhaupt nicht auslöst. Trotzdem lässt der Compiler das durch.

Beim Aufruf solcher Methoden in try-Blöcken müssen in den catch-Klauseln die zu viel deklarierten Exceptions aufgefangen werden, auch wenn sie nicht wirklich erreicht werden können:

Listing 8.33    src/main/java/com/tutego/insel/exception/TooManyExceptions.java, useFile()

try {

  openFile();

}

catch ( IOException e ) { }

catch ( InterruptedException e ) { }

Der Sinn besteht darin, dass dies später in einer Erweiterung einer Methode, etwa einer InterruptedException, durchaus vorkommen kann, und dann sind die Aufrufer darauf schon vorbereitet.