Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Exceptions
7 Äußere.innere Klassen
8 Besondere Klassen der Java SE
9 Generics<T>
10 Architektur, Design und angewandte Objektorientierung
11 Die Klassenbibliothek
12 Einführung in die nebenläufige Programmierung
13 Einführung in Datenstrukturen und Algorithmen
14 Einführung in grafische Oberflächen
15 Einführung in Dateien und Datenströme
16 Einführung in die <XML>-Verarbeitung mit Java
17 Einführung ins Datenbankmanagement mit JDBC
18 Bits und Bytes und Mathematisches
19 Die Werkzeuge des JDK
A Die Klassenbibliothek
Stichwort

Download:
- Aufgaben, ca. 1,1 MB
- Programme, ca. 12,8 MB

Buch bestellen
Ihre Meinung?

Spacer
Java ist auch eine Insel von Christian Ullenboom
Das umfassende Handbuch
Buch: Java ist auch eine Insel

Java ist auch eine Insel
Galileo Computing
1308 S., 10., aktualisierte Auflage, geb., mit DVD
ca. 49,90 Euro, ISBN 978-3-8362-1802-3
Pfeil 9 Generics<T>
Pfeil 9.1 Einführung in Java Generics
Pfeil 9.1.1 Mensch versus Maschine: Typprüfung des Compilers und der Laufzeitumgebung
Pfeil 9.1.2 Taschen
Pfeil 9.1.3 Generische Typen deklarieren
Pfeil 9.1.4 Generics nutzen
Pfeil 9.1.5 Diamonds are forever
Pfeil 9.1.6 Generische Schnittstellen
Pfeil 9.1.7 Generische Methoden/Konstruktoren und Typ-Inferenz
Pfeil 9.2 Umsetzen der Generics, Typlöschung und Raw-Types
Pfeil 9.2.1 Realisierungsmöglichkeiten
Pfeil 9.2.2 Typlöschung (Type Erasure)
Pfeil 9.2.3 Probleme aus der Typlöschung
Pfeil 9.2.4 Raw-Type
Pfeil 9.3 Einschränken der Typen über Bounds
Pfeil 9.3.1 Einfache Einschränkungen mit extends
Pfeil 9.3.2 Weitere Obertypen mit &
Pfeil 9.4 Typparameter in der throws-Klausel *
Pfeil 9.4.1 Deklaration einer Klasse mit Typvariable <E extends Exception>
Pfeil 9.4.2 Parametrisierter Typ bei Typvariable <E extends Exception>
Pfeil 9.5 Generics und Vererbung, Invarianz
Pfeil 9.5.1 Arrays sind invariant
Pfeil 9.5.2 Generics sind kovariant
Pfeil 9.5.3 Wildcards mit ?
Pfeil 9.5.4 Bounded Wildcards
Pfeil 9.5.5 Bounded-Wildcard-Typen und Bounded-Typvariablen
Pfeil 9.5.6 Das LESS-Prinzip
Pfeil 9.5.7 Enum<E extends Enum<E>> *
Pfeil 9.6 Konsequenzen der Typlöschung: Typ-Token, Arrays und Brücken *
Pfeil 9.6.1 Typ-Token
Pfeil 9.6.2 Super-Type-Token
Pfeil 9.6.3 Generics und Arrays
Pfeil 9.6.4 Brückenmethoden

Rheinwerk Computing - Zum Seitenanfang

9.4 Typparameter in der throws-Klausel *Zur nächsten Überschrift

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.


Rheinwerk Computing - Zum Seitenanfang

9.4.1 Deklaration einer Klasse mit Typvariable <E extends Exception>Zur nächsten ÜberschriftZur vorigen Überschrift

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() );

Rheinwerk Computing - Zum Seitenanfang

9.4.2 Parametrisierter Typ bei Typvariable <E extends Exception>Zur nächsten ÜberschriftZur vorigen Überschrift

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.

API-Design der Klasse Scanner

Scanner ist ein Beispiel für eine Klasse, in der die Java-API-Designer geprüfte Ausnahmen bei den next()-Methoden nicht haben wollten. Die Klasse kann normale Strings zerlegen, bei denen next() keine IOException auslösen kann. Aber Scanner kann auch einen Eingabestrom bekommen, und dann sind Ein-/Ausgabeausnahmen durchaus möglich. Was also tun? Entweder bei den next()-Methoden immer eine IOExeption auslösen oder nie? Lösen sie keine Ausnahme aus (das ist das Design jetzt), so bleiben die Fehler auf der Strecke, die beim Einlesen aus dem Datenstrom auftreten können. Trügen die next()-Methoden jedoch ein throws IOException, dann wäre das lästig beim Zerlegen von puren Strings – und das wollten die Entwickler nicht. Daher fällt die IOException bei next() unter den Tisch und muss explizit über die Methode ioException() erfragt werden. Das steht so ganz im Gegensatz zu der Idee, bei Ein-/Ausgabefehlern immer geprüfte Ausnahmen zu verwenden. Beim PrintWriter ist das übrigens genauso, die write() und printXXX()-Methoden lösen keine IOException aus, sondern Entwickler fragen später mit checkError() nach, ob es Probleme gab. Leser können überlegen, ob Scanner<E extends Exception> und Methoden wie next() throws E das Problem lösen würden.



Ihr Kommentar

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

>> Zum Feedback-Formular
<< zurück
  Zum Katalog
Zum Katalog: Java ist auch eine Insel





Java ist auch eine Insel
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Java ist auch eine Insel






 Java ist auch
 eine Insel


Zum Katalog: Java SE Bibliotheken






 Java SE Bibliotheken


Zum Katalog: Professionell entwickeln mit Java EE 7






 Professionell
 entwickeln mit
 Java EE 7


Zum Katalog: Einstieg in Eclipse






 Einstieg in
 Eclipse


Zum Katalog: Einstieg in Java






 Einstieg in
 Java


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de