9.4 Typparameter in der throws-Klausel *

Wir haben im Abschnitt »Keine generischen Ausnahmen« gesehen, dass durch die Typlöschung eine Konstruktion wie class MyException<T> extends Exception nicht möglich ist. Allerdings ist ein Typparameter in der throws-Klausel erlaubt. Das gibt interessante Möglichkeiten für Klassen, die je nach Anwendungsfall einmal geprüfte oder ungeprüfte Ausnahmen auslösen können.

9.4.1 Deklaration einer Klasse mit Typvariable <E extends Exception>

Unsere Schnittstelle CharIterable soll von Klassen implementiert werden, die einen Strom von Zeichen liefen. CharIterable ist ein generischer Schnittstellentyp mit einem formalen Typparameter, der später eine Unterklasse von Exception sein muss:

Listing 9.11: com/tutego/insel/generic/CharIterable.java, CharIterable

public interface CharIterable<E extends Exception>
{
  boolean hasNext() throws E;
  char    next()    throws E;
}

Zeichen können etwa aus einer Datei, von einer Internetressource oder von einem String kommen, doch die Nutzung sieht immer gleich aus:

while ( iter.hasNext() )
  System.out.print( iter.next() );

9.4.2 Parametrisierter Typ bei Typvariable <E extends Exception>

Kommen wir zu den Klassen, die CharIterable implementieren, sodass Nutzer mit der gerade vorgestellten Schleife die Zeichen ablaufen können. Die Deklaration der Schnittstelle CharIterable<E extends Exception> enthält eine auf Exception eingeschränkte Typvariable, was zum Beispiel die folgenden Implementierungen zulässt:

• class StringIterable implements CharIterable<RuntimeException>
• class WebIterable implements CharIterable<IOException>

Kommen im Fall von StringIterable die Zeichen aus einem String, ist keine Ein-/Ausgabe-Ausnahme zu erwarten, daher ist der Typparameter RuntimeException. Beim Lesen aus Dateien oder Internetressourcen kann es jedoch zu IOExceptions kommen, sodass WebIterable den Typparameter IOException wählt.

Beispielimplementierungen für den parametrisierten Typ

Implementieren wir die beiden Klassen StringIterable und WebIterable. Da StringIterable bei der Implementierung der Schnittstelle den Typparameter RuntimeException wählt, führt das zu einem throws RuntimeException, was wiederum optional ist und weggelassen werden kann.

Listing 9.12: com/tutego/insel/generic/StringIterable.java, StringIterable

public class StringIterable implements CharIterable<RuntimeException>
{
  private final String string;
  private int   pos;

  public StringIterable( String string )
  {
    this.string = string;
  }

  @Override public boolean hasNext()
  {
    return pos < string.length();
  }

  @Override public char next()
  {
    return string.charAt( pos++ );
  }
}

Bei WebIterable sieht das anders an. Hier ist der Typparameter IOException, und somit ist ein throws IOException an der Methodensignatur nötig.

Listing 9.13: com/tutego/insel/generic/WebIterable.java, WebIterable

public class WebIterable implements CharIterable<IOException>
{
  private final Reader reader;

  public WebIterable( String url ) throws IOException
  {
    reader = new InputStreamReader( new URL( url ).openStream() ) ;
  }

  @Override public boolean hasNext() throws IOException
  {
    return reader.ready();
  }

  @Override public char next() throws IOException
  {
    return (char) reader.read();
  }
}

Nutzen von StringIterable und WebIterable

Das folgende Beispiel zeigt, dass beim Ablaufen eines Strings keine Ausnahmebehandlung nötig ist, beim Lesen von Zeichen aus dem Internet aber schon:

Listing 9.14: com/tutego/insel/generic/CharReadableExample.java, main()

StringIterable iter1 = new StringIterable( "Shasha" );   // try ist unnötig
while ( iter1.hasNext() )
  System.out.print( iter1.next() );

System.out.println();

try
{
  WebIterable iter2 = new WebIterable( "http://java-tutor.com/aufgaben/bond.txt" );
  while ( iter2.hasNext() )
    System.out.print( iter2.next() );
}
catch ( IOException e )
{
  e.printStackTrace();
}

Statt StringIterable iter1 = new StringIterable... hätten wir natürlich auch CharIterable<RuntimeException> iter1... schreiben können und analog CharIterable<IOException> iter2 statt WebIterable iter2.

Zusammenfassung

Das Beispiel macht deutlich, dass ein Typparameter RuntimeException selbst so elementare Dinge wie geprüfte Ausnahmen ausschaltet. Die Besonderheit liegt beim Compiler, dass er Dinge wie throws E zulässt und dass E dann einmal eine geprüfte oder ungeprüfte Ausnahme sein kann. Exakt so hatten wir CharIterable deklariert:

public interface CharIterable<E extends Exception>
{
  boolean hasNext() throws E;
  char    next()    throws E;
}

Das ist sehr praktisch, denn unser Anwendungsfall macht deutlich, dass es gut ist, einmal geprüfte Ausnahmen zu verwenden, denn geprüfte Aufnahmen verlangen ja immer etwas mehr Aufwand und sind immer nötig, wie das Ablaufen von Strings zeigt.

Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.