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

Pfeil8 Ausnahmen müssen sein
Pfeil8.1 Problembereiche einzäunen
Pfeil8.1.1 Exceptions in Java mit try und catch
Pfeil8.1.2 Geprüfte und ungeprüfte Ausnahmen
Pfeil8.2 Geprüfte Ausnahmen
Pfeil8.2.1 Letzte ausgeführte Java-Programme loggen
Pfeil8.2.2 try-catch-Behandlung
Pfeil8.2.3 throws im Methodenkopf angeben
Pfeil8.3 Ungeprüfte Ausnahmen (RuntimeException)
Pfeil8.3.1 Eine NumberFormatException fliegt
Pfeil8.3.2 Bekannte RuntimeException-Klassen
Pfeil8.3.3 Kann man abfangen, muss man aber nicht
Pfeil8.4 Gut gefangen
Pfeil8.4.1 Bitte nicht schlucken – leere catch-Blöcke
Pfeil8.4.2 Wiederholung abgebrochener Bereiche *
Pfeil8.4.3 Mehrere Ausnahmen auffangen
Pfeil8.4.4 Ablauf einer Ausnahmesituation
Pfeil8.4.5 Abschlussbehandlung mit finally
Pfeil8.5 Die Klassenhierarchie der Ausnahmen
Pfeil8.5.1 Eigenschaften des Exception-Objekts
Pfeil8.5.2 Basistyp Throwable
Pfeil8.5.3 Die Exception-Hierarchie
Pfeil8.5.4 Oberausnahmen auffangen
Pfeil8.5.5 Schon gefangen?
Pfeil8.5.6 Alles geht als Exception durch
Pfeil8.5.7 Zusammenfassen gleicher catch-Blöcke mit dem multi-catch
Pfeil8.6 Auslösen eigener Exceptions
Pfeil8.6.1 Mit throw Ausnahmen auslösen
Pfeil8.6.2 Vorhandene Runtime-Ausnahmetypen kennen und nutzen
Pfeil8.6.3 Parameter testen und gute Fehlermeldungen
Pfeil8.6.4 Neue Exception-Klassen deklarieren
Pfeil8.6.5 Eigene Ausnahmen als Unterklassen von Exception oder RuntimeException?
Pfeil8.6.6 Ausnahmen abfangen und weiterleiten *
Pfeil8.6.7 Aufruf-Stack von Ausnahmen verändern *
Pfeil8.6.8 Präzises rethrow *
Pfeil8.6.9 Geschachtelte Ausnahmen *
Pfeil8.7 Automatisches Ressourcen-Management (try mit Ressourcen)
Pfeil8.7.1 try mit Ressourcen
Pfeil8.7.2 Die Schnittstelle AutoCloseable
Pfeil8.7.3 Mehrere Ressourcen nutzen
Pfeil8.7.4 try mit Ressourcen auf null-Ressourcen
Pfeil8.7.5 Ausnahmen vom close()
Pfeil8.7.6 Unterdrückte Ausnahmen *
Pfeil8.8 Besonderheiten bei der Ausnahmebehandlung *
Pfeil8.8.1 Rückgabewerte bei ausgelösten Ausnahmen
Pfeil8.8.2 Ausnahmen und Rückgaben verschwinden – das Duo return und finally
Pfeil8.8.3 throws bei überschriebenen Methoden
Pfeil8.8.4 Nicht erreichbare catch-Klauseln
Pfeil8.9 Harte Fehler – Error *
Pfeil8.10 Assertions *
Pfeil8.10.1 Assertions in eigenen Programmen nutzen
Pfeil8.10.2 Assertions aktivieren und Laufzeit-Errors
Pfeil8.10.3 Assertions feiner aktivieren oder deaktivieren
Pfeil8.11 Zum Weiterlesen
 

Zum Seitenanfang

8.3    Ungeprüfte Ausnahmen (RuntimeException) Zur vorigen ÜberschriftZur nächsten Überschrift

Einige Arten von Ausnahmen können potenziell an vielen Programmstellen auftreten, etwa eine ganzzahlige Division durch null[ 181 ](Fließkommadivisionen durch 0,0 ergeben entweder ± unendlich oder NaN. ) oder ungültige Indexwerte beim Zugriff auf Array-Elemente. Treten solche Ausnahmen beim Programmlauf auf, liegt ihnen in der Regel ein Denkfehler des Programmierers zugrunde, und das Programm sollte normalerweise nicht versuchen, die ausgelöste Ausnahme aufzufangen und zu behandeln. Daher gibt es in der Java-API mit der Klasse RuntimeException eine Unterklasse von Exception, die Programmierfehler aufzeigt, die behoben werden müssen. (Der Name »RuntimeException« ist jedoch seltsam gewählt, da alle Ausnahmen immer zur Runtime, also zur Laufzeit, erzeugt, ausgelöst und behandelt werden. Doch drückt er aus, dass der Compiler sich für diese Ausnahmen nicht interessiert, sondern erst die JVM zur Laufzeit.)

[»]  Hinweis

Es funktioniert gut, eine RuntimeException als Selbst-schuld-Fehler zu sehen. Durch sachgemäße Prüfung, z. B. der Wertebereiche, würden viele RuntimeExceptions nicht entstehen.

 

Zum Seitenanfang

8.3.1    Eine NumberFormatException fliegt Zur vorigen ÜberschriftZur nächsten Überschrift

Über die Methode Integer.parseInt(…) haben wir an verschiedenen Stellen schon gesprochen. Sie konvertiert eine Zahl, die als Zeichenkette gegeben ist, in eine Dezimalzahl:

int vatRate = Integer.parseInt( "19" );

In dem Beispiel ist eine Konvertierung möglich, und die Methode führt die Umwandlung ohne Ausnahme aus. Anders sieht das aus, wenn der String keine Zahl repräsentiert:

Listing 8.3    src/main/java/com/tutego/insel/exception/MissNumberFormatException.java

package com.tutego.insel.exception;           /* 1 */

public class MissNumberFormatException { /* 2 */

public static int getVatRate() { /* 3 */

return Integer.parseInt( "19%" ); /* 4 */

} /* 5 */

public static void main( String[] args ) { /* 6 */

System.out.println( getVatRate() ); /* 7 */

} /* 8 */

} /* 9 */

Die Ausführung des Programms bricht mit einer Ausnahme ab, und die virtuelle Maschine gibt uns automatisch eine Meldung aus:

Exception in thread "main" java.lang.NumberFormatException: For input string: "19%"

at java.base/java.lang.NumberFormatException.forInputString(

NumberFormatException.java:65)

at java.base/java.lang.Integer.parseInt(Integer.java:652)

at java.base/java.lang.Integer.parseInt(Integer.java:770)

at c.t.i.e.MissNumberFormatException.getVatRate(MissNumberFormatException.java:4)

at e.t.i.e.MissNumberFormatException.main(MissNumberFormatException.java:7)

In der ersten Zeile können wir ablesen, dass eine java.lang.NumberFormatException ausgelöst wurde. In der letzten Zeile steht, welche Stelle in unserem Programm zu der Ausnahme führte. (Fehlerausgaben wie diese haben wir schon im Abschnitt »Auf null geht nix, nur die NullPointerException« in Abschnitt 3.7.1, »null-Referenz und die Frage der Philosophie«, beobachtet.)

Eclipse zeigt eine Exception im Ausgabefenster in Rot an. Praktischerweise verhalten sich die Fehlermeldungen wie Hyperlinks: Ein Klick, und Eclipse zeigt die Zeile, die die Exception auslöst.

Abbildung 8.2    Eclipse zeigt eine Exception im Ausgabefenster in Rot an. Praktischerweise verhalten sich die Fehlermeldungen wie Hyperlinks: Ein Klick, und Eclipse zeigt die Zeile, die die Exception auslöst.

Auch bei IntelliJ führt ein Klick auf die Fehlerstelle und in den Quellcode.

Abbildung 8.3    Auch bei IntelliJ führt ein Klick auf die Fehlerstelle und in den Quellcode.

Eine NumberFormatException auffangen

Dass ein Programm einfach so abbricht und die JVM endet, ist üblicherweise keine Lösung. Ausnahmen sollten aufgefangen und gemeldet werden. Um Ausnahmen aufzufangen, ist es erst einmal wichtig, zu wissen, was genau für eine Ausnahme ausgelöst wird. In unserem Fall ist das einfach abzulesen, denn die Ausnahme ist ja schon aufgetaucht und klar einem Grund zuzuordnen. Die Java-Dokumentation nennt diese Ausnahme auch, und weil ohne die aufgefangene Ausnahme das Programm abbricht, soll nun die NumberFormatException aufgefangen werden. Dabei kommt wieder die try-catch-Konstruktion zum Einsatz:

Listing 8.4    src/main/java/com/tutego/insel/exception/CatchNumberFormatException.java, main()

String stringToConvert = "19%";

double vat = 19;

try {

vat = Integer.parseInt( stringToConvert );

}

catch ( NumberFormatException e ) {

System.err.printf( "'%s' kann man nicht in eine Zahl konvertieren!%n",

stringToConvert );

}

System.out.printf( "Weiter geht's mit MwSt=%g%n", vat );

Die gesamte Ausgabe ist:

'19%' kann man nicht in eine Zahl konvertieren!

Weiter geht's mit MwSt=19,0000

Integer.parseInt("19%") führt, da der String keine Zahl ist, zu einer NumberFormatException, die wir behandeln, und danach geht es mit der Konsolenausgabe weiter.

 

Zum Seitenanfang

8.3.2    Bekannte RuntimeException-Klassen Zur vorigen ÜberschriftZur nächsten Überschrift

Die Java-API bietet insgesamt eine große Anzahl von RuntimeException-Klassen, und es werden immer mehr. Tabelle 8.1 listet einige bekannte Ausnahmetypen auf und zeigt, welche Operationen die Ausnahmen auslösen. Wir greifen hier schon auf spezielle APIs vor, die erst später im Buch vorgestellt werden.

Unterklasse von RuntimeException

Was den Fehler auslöst

ArithmeticException

ganzzahlige Division durch 0

ArrayIndexOutOfBoundsException

Indexgrenzen wurden missachtet, etwa durch (new int[0])[1]. Eine ArrayIndexOutOfBoundsException ist neben der StringIndexOutOfBoundsException eine Unterklasse von IndexOutOfBoundsException.

ClassCastException

Eine Typumwandlung ist zur Laufzeit nicht möglich. So löst String s = (String) new Object(); eine ClassCastException mit der Meldung »java.lang. Object cannot be cast to java.lang.String« aus.

EmptyStackException

Der Stapelspeicher ist leer. new java.util.Stack(). pop() provoziert den Fehler.

IllegalArgumentException

Eine häufig verwendete Ausnahme, mit der Methoden falsche Argumente melden. Integer.parseInt("tutego") löst eine NumberFormatException, eine Unterklasse von IllegalArgumentException, aus.

IllegalMonitorStateException

Ein Thread möchte warten, hat aber den Monitor nicht. Ein Beispiel: new String().wait();

NullPointerException

Meldet einen der häufigsten Programmierfehler, beispielsweise durch ((String) null).length().

UnsupportedOperationException

Operationen sind nicht gestattet, etwa durch java.util.Arrays.asList(args).add("jv").

Tabelle 8.1    »RuntimeException«-Klassen

 

Zum Seitenanfang

8.3.3    Kann man abfangen, muss man aber nicht Zur vorigen ÜberschriftZur nächsten Überschrift

Eine RuntimeException kann im Code abgefangen werden, muss es aber nicht. Da der Compiler nicht auf einem Abfangen besteht, heißen die aus RuntimeException hervorgegangenen Ausnahmen auch ungeprüfte Ausnahmen bzw. nichtgeprüfte Ausnahmen (engl. unchecked exceptions), und alle übrigen heißen geprüfte Ausnahmen (engl. checked exceptions). Auch muss eine RuntimeException nicht unbedingt bei throws in der Methodensignatur angegeben werden, obwohl einige Autoren das zur Dokumentation machen.

Praktisch ist, dass eine ungeprüfte Ausnahme entlang der Kette von Methodenaufrufen wie eine Blase (engl. bubble) nach oben steigen und irgendwann von einem Block abgefangen werden kann, der sich darum kümmert. Tritt eine RuntimeException zur Laufzeit auf und kommt nicht irgendwann in der Aufrufhierarchie ein try-catch, beendet die JVM den ausführenden Thread. Löst also eine in main(…) aufgerufene Aktion eine RuntimeException aus, ist das das Ende für dieses Hauptprogramm.

[+]  Style

Eine RuntimeException wird nicht im Methodenkopf angegeben, sollte aber im Javadoc dokumentiert werden.

 


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