Rheinwerk Computing < openbook >


 
Inhaltsverzeichnis
Materialien
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Arrays und ihre Anwendungen
5 Der Umgang mit Zeichenketten
6 Eigene Klassen schreiben
7 Objektorientierte Beziehungsfragen
8 Ausnahmen müssen sein
9 Geschachtelte Typen
10 Besondere Typen der Java SE
11 Generics<T>
12 Lambda-Ausdrücke und funktionale Programmierung
13 Architektur, Design und angewandte Objektorientierung
14 Java Platform Module System
15 Die Klassenbibliothek
16 Einführung in die nebenläufige Programmierung
17 Einführung in Datenstrukturen und Algorithmen
18 Einführung in grafische Oberflächen
19 Einführung in Dateien und Datenströme
20 Einführung ins Datenbankmanagement mit JDBC
21 Bits und Bytes, Mathematisches und Geld
22 Testen mit JUnit
23 Die Werkzeuge des JDK
A Java SE-Module und Paketübersicht
Stichwortverzeichnis


Download:

- Listings, ca. 2,7 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil 11 Generics<T>
Pfeil 11.1 Einführung in Java Generics
Pfeil 11.1.1 Mensch versus Maschine – Typprüfung des Compilers und der Laufzeitumgebung
Pfeil 11.1.2 Raketen
Pfeil 11.1.3 Generische Typen deklarieren
Pfeil 11.1.4 Generics nutzen
Pfeil 11.1.5 Diamonds are forever
Pfeil 11.1.6 Generische Schnittstellen
Pfeil 11.1.7 Generische Methoden/Konstruktoren und Typ-Inferenz
Pfeil 11.2 Umsetzen der Generics, Typlöschung und Raw-Types
Pfeil 11.2.1 Realisierungsmöglichkeiten
Pfeil 11.2.2 Typlöschung (Type Erasure)
Pfeil 11.2.3 Probleme der Typlöschung
Pfeil 11.2.4 Raw-Type
Pfeil 11.3 Die Typen über Bounds einschränken
Pfeil 11.3.1 Einfache Einschränkungen mit extends
Pfeil 11.3.2 Weitere Obertypen mit &
Pfeil 11.4 Typparameter in der throws-Klausel *
Pfeil 11.4.1 Deklaration einer Klasse mit Typvariable <E extends Exception>
Pfeil 11.4.2 Parametrisierter Typ bei Typvariable <E extends Exception>
Pfeil 11.5 Generics und Vererbung, Invarianz
Pfeil 11.5.1 Arrays sind kovariant
Pfeil 11.5.2 Generics sind nicht kovariant, sondern invariant
Pfeil 11.5.3 Wildcards mit ?
Pfeil 11.5.4 Bounded Wildcards
Pfeil 11.5.5 Bounded-Wildcard-Typen und Bounded-Typvariablen
Pfeil 11.5.6 Das LESS-Prinzip
Pfeil 11.5.7 Enum<E extends Enum<E>> *
Pfeil 11.6 Konsequenzen der Typlöschung: Typ-Token, Arrays und Brücken *
Pfeil 11.6.1 Typ-Token
Pfeil 11.6.2 Super-Type-Token
Pfeil 11.6.3 Generics und Arrays
Pfeil 11.6.4 Brückenmethoden
Pfeil 11.7 Zum Weiterlesen
 

Zum Seitenanfang

11.4    Typparameter in der throws-Klausel * Zur vorigen ÜberschriftZur nächsten Überschrift

Wir haben in Abschnitt 11.2.3, »Probleme der Typlöschung«, 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.

 

Zum Seitenanfang

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

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

Listing 11.12    src/main/java/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() );
 

Zum Seitenanfang

11.4.2    Parametrisierter Typ bei Typvariable <E extends Exception> Zur vorigen ÜberschriftZur nächsten Ü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-/Ausgabeausnahme zu erwarten. Daher ist das Typargument RuntimeException. Beim Lesen aus Dateien oder Internetressourcen kann es jedoch zu IOExceptions kommen, sodass WebIterable das Typargument IOException wählt.

Beispielimplementierungen für den parametrisierten Typ

Implementieren wir die beiden Klassen StringIterable und WebIterable. Da StringIterable bei der Implementierung der Schnittstelle das Typargument RuntimeException wählt, führt das zu einer throws RuntimeException, wobei die throws-Klausel wiederum optional ist und weggelassen werden kann:

Listing 11.13    src/main/java/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 aus. Hier ist das Typargument IOException, und somit ist ein throws IOException an der Methodensignatur nötig:

Listing 11.14    src/main/java/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 11.15    src/main/java/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://tutego.de/javabuch/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 Typargument 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 ungeprüfte Ausnahmen, wie beim Ablaufen von Strings bei StringIterable, gut möglich sind; geprüfte Ausnahmen verlangen ja immer etwas mehr Aufwand.

[»]  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 die next()-Methoden keine Ausnahme aus (das ist das Design zurzeit), so bleiben die Fehler auf der Strecke, die beim Einlesen aus dem Datenstrom auftreten können. Würden die next()-Methoden jedoch eine throws IOException deklarieren, 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.

 


Ihre Meinung?

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de

<< zurück
 Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java ist auch eine Insel Java ist auch eine Insel

Jetzt Buch bestellen


 Buchempfehlungen
Zum Rheinwerk-Shop: Captain CiaoCiao erobert Java

Captain CiaoCiao erobert Java




Zum Rheinwerk-Shop: Java SE 9 Standard-Bibliothek

Java SE 9 Standard-Bibliothek




Zum Rheinwerk-Shop: Algorithmen in Java

Algorithmen in Java




Zum Rheinwerk-Shop: Objektorientierte Programmierung

Objektorientierte Programmierung




 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und in die Schweiz

InfoInfo



 

 


Copyright © Rheinwerk Verlag GmbH 2021

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



Cookie-Einstellungen ändern