8.2 Geprüfte Ausnahmen 
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.
8.2.1 Letzte ausgeführte Java-Programme loggen
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 );
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:
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.
8.2.2 try-catch-Behandlung
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.
8.2.3 throws im Methodenkopf angeben
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.
Java ist auch eine Insel
