7.3 Werfen eigener Exceptions 

Bisher wurden Exceptions lediglich aufgefangen, aber noch nicht selbst erzeugt. Routinen, die durch Exceptions das Misslingen einer Operation anzeigen, finden sich im Laufzeitsystem oder in der Standardbibliothek zu Genüge. Soll eine Funktion selbst eine Exception auslösen, muss sie ein Exception-Objekt erzeugen und die Ausnahmebehandlung anstoßen. Im Sprachschatz dient das Schlüsselwort throw dazu, eine Ausnahme auszulösen:

public void ichKann( String s )
{
  if ( ! kannIchWasMitStringMachen( s ) )
    throw new SecurityException ( "Ätsch, das kannst du mit " + s +
                                  " nicht machen!" );
}

Kann mit der übergebenen Zeichenkette s eine bestimmte Operation nicht ausgeführt werden, so wird mit new ein SecurityException-Objekt erzeugt, und diesem eine Zeichenkette als Fehlermeldung mit auf den Weg gegeben. Für nicht passende Werte sieht die Standardbibliothek etwa die Fehlerklasse IllegalArgumentException vor.

Gerne werden Exceptions in den default-Zweig einer switch-Anweisung mit hineingenommen. Im folgenden Beispiel wird versucht, ein Exemplar der Klasse Schokolade mit einer Farbe zu erzeugen. Sollte der Übergabeparameter falsch sein, so wird eine Illegal ArgumentException ausgelöst.

Listing 7.7   Schokolade.java

class Schokolade
{
  public final static int WEISS = 0, BRAUN = 1;

  private int farbe;

  Schokolade( int f )
  {
    switch( f )
    {
      case WEISS:
      case BRAUN: farbe = f;
                  break;
      default   : throw new IllegalArgumentException(
                               "Falsche Schoko-Farbe: " + f );
     }
  }

  public void test()
  {
    System.out.println( "Aha, du magst also " +
                        ( ( farbe == WEISS) ? "weisse " : "braune " ) +
                        "Schokolade gerne!" );
  }
  public static void main( String args[] )
  {
//    Schokolade ws = new Schokolade( Schokolade.BRAUN );
    Schokolade ws = new Schokolade( 4 );
    ws.test();
  }
}

Es ist bei diesem Programm deutlich, dass die Fehlerquelle dadurch verringert wird, dass Konstanten die Eigenschaften des Objekts beschreiben. Nach dem Aufruf bekommen wir folgende Meldung:

java.lang.IllegalArgumetException: Falsche Schoko-Farbe: 4
        at Schokolade.<init>(Schokolade.java:13)
        at Schokolade.main(Schokolade.java:28)

7.3.1 Vorgefertigte Ausnahme-Objekte wiederverwenden 

Da bei einer Ausnahme ein Exception-Objekt angelegt wird und die übliche Zeit für das Anlegen von Objekten anfällt, lässt sich diese Zeit sparen, indem eine Referenz auf ein vorgefertigtes Objekt gelegt wird. Hieß es vorher

void foo()
{
  ...
  throw new XYZException();
  ...
}

so kann es nun wie folgt aussehen:

private static XYZException xyzException = new XYZException();

void foo()
{
  ...
  throw xyzException;
  ...
}

Sinnvoll erscheint dies jedoch nur dann, wenn häufig Ausnahmen ausgelöst werden, was allerdings nicht die Regel sein sollte. Zudem handelt es sich hier um eine Wiederverwendung des Standardfehler-Objekts. Parametrisierte Konstruktoren werden oft mit individuellen Werten gefüttert. Hier ist im Vorfeld keine Belegung bekannt, sodass sich das Ausnahme-Objekt nicht anlegen lässt. Ein weiteres Problem ist, dass im Fehlerfall der Stacktrace des Objekts nur die Erzeugungsstelle im Konstruktor beziehungsweise im statischen Initialisierer der umgebenden Klasse angibt, statt der echten Fehlerstelle, von der es ja unter Umständen viele geben kann.

7.3.2 Typecast auf ein null-Objekt für eine NullPointerException 

Mit einem anderen Trick lässt sich die manuelle Objekterzeugung beim Auslösen einer Exception umgehen. Werfen wir einen Blick auf folgendes Codebeispiel:

Listing 7.8   ThrowNull.java

class ThrowNull
{
  static void bar()
  {
    throw (RuntimeException) null;

  }

  public static void main( String args[] )
  {
    bar();
  }
}

Das Programm kompiliert und löst eine NullPointerException aus.

java.lang.NullPointerException
  at ThrowNull.bar(ThrowNull.java:5)
  at ThrowNull.main(ThrowNull.java:10)

Da wir null auf RuntimeException casten, müssen wir auch kein throws in der Methodendeklaration angeben und den Fehler auch nicht bei bar() behandeln. Das ist aber ein recht fragwürdiger Stil, da hier das hierarchische Typsystem für Fehlerarten unterlaufen wird und alle Fehler zur NullPointerException werden.

7.3.3 Neue Exception-Klassen definieren 

Eigene Fehlerarten werden definiert, indem die Klasse Exception in einer Unterklasse erweitert wird. Dabei werden oft zwei Konstruktoren verwendet, ein Standard-Konstruktor und ein zweiter mit einem String als Parameter. Um für die Klasse Schokolade im letzten Beispiel einen neuen Fehlertyp zu definieren, erweitern wir IllegalArgumentException zur illegalen Schoko-Farbe.

Listing 7.9   IllegalSchokoColorException.java

public class IllegalSchokoColorException extends IllegalArgumentException

{
  public IllegalSchokoColorException()
  {
    super();
  }

  public IllegalSchokoColorException( String s )
  {
    super( s );
  }
}

Nehmen wir uns die Abfrage noch einmal vor, dann wird an Stelle der vorherigen IllegalArgumentException eine IllegalSchokoColorException ausgelöst:

throw new IllegalSchokoColorException(
  "Diese Schokoladen-Farbe gibt es nicht: " + f );

Im Hauptprogramm können wir auf diese Ausnahme reagieren: Entweder wir fangen in einem Aufruf IllegalSchokoColorException ab oder wir lassen die spezielle IllegalArgumentException, die ja eine RuntimeExeption ist und daher nicht abgefangen zu werden braucht, die JVM beenden. Um die alte Schokoladen-Klasse mit der IllegalArgumentexception von der neuen mit der eigenen Fehlerklasse IllegalSchokoColorException zu trennen, nennen wir die neue Klasse Schokolade2.

Listing 7.10   Schokolade2.java

  public static void main( String args[] )
  {
    try
    {
      Schokolade2 ws = new Schokolade2( 4 );
      ws.test();
    }
    catch( IllegalSchokoColorException isce )
    {
      System.err.println( "Falsche Schokoladen-Farbe abgefangen" );
      isce.printStackTrace();
    }

    System.err.println();
    Schokolade2 ws1 = new Schokolade2(3);
    ws1.test();          // Abbruch duch IllegalSchokoColorException
  }
}

Die erwartete Ausgabe ist:

Falsche Schokoladen-Farbe abgefangen
IllegalSchokoColorException: Diese Schokoladen-Farbe gibt es nicht: 4
 at Schokolade2.<init>(Schokolade2.java:26)
 at Schokolade2.main(Schokolade2.java:40)

IllegalSchokoColorException: Diese Schokoladen-Farbe gibt es nicht: 3
 at Schokolade2.<init>(Schokolade2.java:26)
 at Schokolade2.main(Schokolade2.java:50)
Exception in thread "main"