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 das übergebene Argument falsch sein, so wird eine IllegalArgumentException 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();
  }
}

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 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.2 Neue Exception-Klassen definieren 

Eigene Exceptions sind direkte oder indirekte Unterklassen von Exception. Sie implementieren oft zwei Konstruktoren: einen Standard-Konstruktor und einen mit einem String parametrisierten Konstruktor. 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 anstelle 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.

Hier klicken, um das Bild zu Vergrößern

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"