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 8 Ausnahmen müssen sein
Pfeil 8.1 Problembereiche einzäunen
Pfeil 8.1.1 Exceptions in Java mit try und catch
Pfeil 8.1.2 Geprüfte und ungeprüfte Ausnahmen
Pfeil 8.2 Geprüfte Ausnahmen
Pfeil 8.2.1 Letzte ausgeführte Java-Programme loggen
Pfeil 8.2.2 try-catch-Behandlung
Pfeil 8.2.3 throws im Methodenkopf angeben
Pfeil 8.3 Ungeprüfte Ausnahmen (RuntimeException)
Pfeil 8.3.1 Eine NumberFormatException fliegt
Pfeil 8.3.2 Bekannte RuntimeException-Klassen
Pfeil 8.3.3 Kann man abfangen, muss man aber nicht
Pfeil 8.4 Gut gefangen
Pfeil 8.4.1 Bitte nicht schlucken – leere catch-Blöcke
Pfeil 8.4.2 Wiederholung abgebrochener Bereiche *
Pfeil 8.4.3 Mehrere Ausnahmen auffangen
Pfeil 8.4.4 Ablauf einer Ausnahmesituation
Pfeil 8.4.5 Abschlussbehandlung mit finally
Pfeil 8.5 Die Klassenhierarchie der Ausnahmen
Pfeil 8.5.1 Eigenschaften des Exception-Objekts
Pfeil 8.5.2 Basistyp Throwable
Pfeil 8.5.3 Die Exception-Hierarchie
Pfeil 8.5.4 Oberausnahmen auffangen
Pfeil 8.5.5 Schon gefangen?
Pfeil 8.5.6 Alles geht als Exception durch
Pfeil 8.5.7 Zusammenfassen gleicher catch-Blöcke mit dem multi-catch
Pfeil 8.6 Auslösen eigener Exceptions
Pfeil 8.6.1 Mit throw Ausnahmen auslösen
Pfeil 8.6.2 Vorhandene Runtime-Ausnahmetypen kennen und nutzen
Pfeil 8.6.3 Parameter testen und gute Fehlermeldungen
Pfeil 8.6.4 Neue Exception-Klassen deklarieren
Pfeil 8.6.5 Eigene Ausnahmen als Unterklassen von Exception oder RuntimeException?
Pfeil 8.6.6 Ausnahmen abfangen und weiterleiten *
Pfeil 8.6.7 Aufruf-Stack von Ausnahmen verändern *
Pfeil 8.6.8 Präzises rethrow *
Pfeil 8.6.9 Geschachtelte Ausnahmen *
Pfeil 8.7 Automatisches Ressourcen-Management (try mit Ressourcen)
Pfeil 8.7.1 try mit Ressourcen
Pfeil 8.7.2 Die Schnittstelle AutoCloseable
Pfeil 8.7.3 Mehrere Ressourcen nutzen
Pfeil 8.7.4 try mit Ressourcen auf null-Ressourcen
Pfeil 8.7.5 Ausnahmen vom close()
Pfeil 8.7.6 Unterdrückte Ausnahmen *
Pfeil 8.8 Besonderheiten bei der Ausnahmebehandlung *
Pfeil 8.8.1 Rückgabewerte bei ausgelösten Ausnahmen
Pfeil 8.8.2 Ausnahmen und Rückgaben verschwinden – das Duo return und finally
Pfeil 8.8.3 throws bei überschriebenen Methoden
Pfeil 8.8.4 Nicht erreichbare catch-Klauseln
Pfeil 8.9 Harte Fehler – Error *
Pfeil 8.10 Assertions *
Pfeil 8.10.1 Assertions in eigenen Programmen nutzen
Pfeil 8.10.2 Assertions aktivieren und Laufzeit-Errors
Pfeil 8.10.3 Assertions feiner aktivieren oder deaktivieren
Pfeil 8.11 Zum Weiterlesen
 

Zum Seitenanfang

8.2    Geprüfte Ausnahmen Zur vorigen ÜberschriftZur nächsten Überschrift

Geprüfte Ausnahmen können von Methoden oder Konstrukturen im Fehlerfall ausgelöst werden. Entwickler müssen sich der Tatsache stellen, dass es knallen könnte, und müssen sich daher wappnen.

 

Zum Seitenanfang

8.2.1    Letzte ausgeführte Java-Programme loggen Zur vorigen ÜberschriftZur nächsten Überschrift

Wir wollen ein kleines Programm schreiben, das das gestartete Java-Programm und die aktuelle Zeit in einer Textdatei anhängt, als eine Art Aufruf-Logger, damit nachverfolgt werden kann, wann ein Java-Programm gestartet wurde. Die aktuelle Zeit bekommen wir mit LocalDateTime, und das laufende Programm lässt sich mit System.getProperty( "sun.java.command" ) identifizieren.[ 180 ](Die Variable ist in allen Java-Laufzeitversionen gesetzt, die auf dem OpenJDK basieren. ) In Dateien können wir mit der Methode Files.writeString(…) schreiben – die Methode ist Bestandteil der Files-API seit Java 11.

Der relevanten Zeilen:

String content = System.getProperty( "sun.java.command" ) + " started at "

+ LocalDateTime.now() + "\n";

Files.writeString( Path.of( "executed_programs.txt" ),

content, StandardOpenOption.APPEND ); inline image

Die Zeilen können so nicht übersetzt werden, und es gibt einen Compilerfehler. Der Grund ist Files.writeString(…), denn diese Methode kann eine IOException auslösen.

Dokumentierte Ausnahmen in der Javadoc

Eine Ausnahme kommt nicht wirklich überraschend, und Entwickler müssen sich darauf vorbereiten, dass, wenn sie etwas Falsches an Methoden oder Konstruktoren übergeben, diese schimpfen. Im besten Fall erklärt die API-Dokumentation, welche Eingaben gültig sind und welche nicht. Zur »Schnittstelle« einer Methode gehört auch das Verhalten im Fehlerfall. Die API-Dokumentation sollte genau beschreiben, welche Ausnahme – oder Reaktion wie spezielle Rückgabewerte – zu erwarten ist, wenn die Methode ungültige Werte erhält. Die Java-Dokumentation bei Files.writeString(…) macht das:

Die Javadoc dokumentiert alle möglichen Ausnahmen.

Abbildung 8.1    Die Javadoc dokumentiert alle möglichen Ausnahmen.

Die Beschreibung »IOException – if an I/O error occurs writing to or creating the file, or the text cannot be encoded using the specified charset« ist vielleicht ein bisschen vage, denn sie erklärt nicht, warum genau der Fehler auftrat. Aber es nützt nichts, wir müssen den Fehler behandeln. Wir sehen auch, dass IOException nicht der einzige Fehler ist, der in der Liste steht. Es könnte auch zu einer IllegalArgumentException, UnsupportedOperationException oder SecurityException kommen, doch hier zwingt uns keiner, diese aufzufangen. Das ist genau der Unterschied zwischen einer geprüften und einer ungeprüften Ausnahme.

 

Zum Seitenanfang

8.2.2    try-catch-Behandlung Zur vorigen ÜberschriftZur nächsten Überschrift

Da Files.writeString(…) eine IOException auslösen kann, und das eine geprüfte Ausnahme ist, die behandelt werden muss, gibt es zwei Lösungen: erstens mit try-catch den Fehler behandeln oder zweitens mit throws den Fehler an die Aufrufstelle weiterleiten.

Lösen wir das Problem in unserem Programm mit der IOException durch eine try-catch-Behandlung:

Listing 8.1    src/main/java/com/tutego/insel/exception/LogCurrentDateTime.java, Ausschnitt

public class LogCurrentDateTime {

public static void logExecutedProgram() {

String content = System.getProperty( "sun.java.command" ) + " started at "

+ LocalDateTime.now() + "\n";

try {

Files.writeString( Path.of( "executed_programs.txt" ),

content, StandardOpenOption.APPEND );

}

catch ( IOException e ) {

e.printStackTrace();

}

}



public static void main( String[] args ) {

logExecutedProgram();

}

}

Der try-Anweisung folgt ein Block, genannt try-Block. Wir nutzen ihn in Kombination mit einer catch-Klausel. Der Code catch(IOException e) deklariert einen Exception-Handler – er fängt alles auf, was vom Ausnahmetyp IOException ist. Die Variable e ist ein Exception-Parameter. Die Nutzung von var ist nicht erlaubt. Da Ausnahmen Objekte sind, referenziert die Variable e dieses Ausnahmeobjekt.

Nach dem Auffangen ist der Fehler wie weggeblasen, und alles geht ganz normal weiter.

Stack-Trace

Die virtuelle Maschine merkt sich auf einem Stapel, welche Methode welche andere Methode aufgerufen hat. Dies nennt sich Stack-Trace. Wenn also die statische main(…)-Methode die Methode logExecutedProgram() aufruft und diese wiederum writeString(…), so sieht der Stapel zum Zeitpunkt von writeString(…) so aus:

writeString

logExecutedProgram

main

Ein Stack-Trace ist im Fehlerfall nützlich, da wir in ihm ablesen können, dass writeString(…) die Ausnahme ausgelöst hat und nicht irgendeine andere Methode.

Oftmals werden im Programm Stack-Traces geloggt. Hierbei hilft eine Methode, die schon im catch-Block steht: e.printStackTrace();. Sie setzt den Stack-Trace standardmäßig auf den System.err-Kanal.

 

Zum Seitenanfang

8.2.3    throws im Methodenkopf angeben Zur vorigen ÜberschriftZur nächsten Überschrift

Neben dem »Einzäunen« von problematischen Blöcken durch einen try-Block mit angehängtem catch-Block zur Behandlung gibt es eine weitere Möglichkeit, auf Exceptions zu reagieren: das Weiterleiten an den Aufrufer. Im Kopf der betreffenden Methode wird dazu eine throws-Klausel eingeführt. Dadurch zeigt die Methode an, dass sie eine bestimmte Exception nicht selbst behandelt, sondern diese an die aufrufende Methode weitergibt. Wird nun von der aufgerufenen Methode eine Exception ausgelöst, so wird diese Methode abgebrochen, und der Aufrufer muss sich um die Ausnahme kümmern.

Wir können unsere Methode logExecutedProgram() so umschreiben, dass sie die Ausnahmen nicht mehr selbst abfängt, sondern nach oben weiterleitet:

Listing 8.2    src/main/java/com/tutego/insel/exception/LogCurrentDateTime2.java, Ausschnitt

public static void logExecutedProgram() throws IOException {

String content = System.getProperty( "sun.java.command" ) + " started at "

+ LocalDateTime.now() + "\n";

Files.writeString( Path.of( "executed_programs.txt" ),

content, StandardOpenOption.APPEND );

}



public static void main( String[] args ) {

try {

logExecutedProgram();

}

catch ( IOException e ) {

e.printStackTrace();

}

}

Nun ist main(…) am Zug und muss sich mit IOException herumärgern. Auch an main(…) könnte ein throws stehen; dann hätte die JVM den schwarzen Peter.

 


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