7.4 Rückgabewerte bei ausgelösten Ausnahmen 

Java versucht, durch Flussanalyse den Programmablauf innerhalb einer Methode zu bestimmen und zu melden, ob definitiv ein Rückgabewert geliefert wird. Dabei werden die Programmpfade verfolgt und Ausdrücke unter Umständen ausgewertet. Doch die Aussage »Jede Funktion mit Ergebnistyp ungleich void muss eine return-Anweisung besitzen« müssen wir etwas relativieren. Nur in einem speziellen Fall müssen wir dies nicht. Nämlich genau dann, wenn vor dem Ende der Funktion eine throws-Anweisung die Abarbeitungsreihenfolge beendet. Sehen wir uns drei Methoden an:

Listing 7.11   NoReturn.java

class NoReturn
{
  int foo()
  {
    throw new RuntimeException();
  }

  void bar()
  {
    if ( true )
      throw new RuntimeException();
  }

  int zof()
  {
    if ( true )    // while würde stattdessen gehen!
      throw new RuntimeException();
  }
}

Ein Blick auf foo() verrät, dass trotz Rückgabewert keine return-Anweisung eingesetzt wird. Die Abarbeitung wird vor dem Rücksprung durch eine Exception abgebrochen. foo() muss diese Exception nicht mit throws ankündigen, da wir wieder ein Exemplar von RuntimeException erzeugen. Bei bar() führt nur eine wahre Bedingung zu einem Abbruch. Da if(true) immer wahr ist, wird die Methode mit einer Exception beendet. Einen Rückgabewert haben wir nicht, daher ist es egal, ob wir ein return einsetzen oder nicht. Interessanter ist da schon die Methode zof(). Wie bei foo() haben wir einen vorgeschriebenen Rückgabewert, aber eine Exception soll dies überflüssig machen. In unseren Gedanken wird if(true) immer ausgeführt und die Exception immer ausgelöst, wie im Fall bar(). Das erkennt der Compiler allerdings nicht und meckert darüber, eine return-Anweisung einzusetzen. Die Flussanalyse geht nicht so weit, den konstanten Ausdruck auszuwerten. Paradoxerweise würde ein while(true) hier funktionieren und auch zof() übersetzungsfähig machen.