Ausnahmen und Dateien in Java

Eine Ausnahme ist ein Objekt, das ein Problem beschreibt, das ein laufendes Programm unterbricht. Wird sie geworfen, stoppt die aktuelle Anweisung. Java überspringt die übrigen normalen Arbeitsschritte, bis es eine passende Ausnahmebehandlung findet; ohne eine solche wird die Ausnahme durch die aufrufenden Methoden zurückgegeben.

Erkenne die Art des Problems

Ein fehlendes Semikolon ist ein Kompilierfehler: Das Programm kann nicht kompiliert werden. Eine Ausnahme tritt auf, wenn kompilierter Code mit Daten ausgeführt wird, die ein Problem auslösen.

Array-Indizes beginnen bei 0, die Länge 3 bedeutet also die gültigen Indizes 0, 1 und 2. Für die Gleitkommadivision gelten andere Regeln: 10.0 / 0 ergibt Infinity; dabei wird nicht die Ausnahme der Ganzzahldivision geworfen.

Lies einen Stacktrace von oben

Hier ist eine vollständige Klasse ohne Leerzeilen vor der ersten Zeile:

public class Average {
    static int average(int[] values) {
        int sum = 0;
        for (int value : values) sum += value;
        return sum / values.length;
    }
    public static void main(String[] args) {
        int[] values = new int[0];
        System.out.println(average(values));
    }
}

Das Array ist leer, seine Länge ist also 0. Die Division in Zeile 5 schlägt fehl. Der Stacktrace lautet:

Exception in thread "main" java.lang.ArithmeticException: / by zero
    at Average.average(Average.java:5)
    at Average.main(Average.java:9)

1. Lies in der ersten Zeile die Ausnahmeklasse und die Meldung.
2. Lies im obersten at-Stapelrahmen die Stelle, an der das Problem erkannt wurde.
3. Lies weiter nach unten zu den Aufrufern: main hat average in Zeile 9 aufgerufen.
4. Gehören die obersten Stapelrahmen zur Java-Bibliothek, suche den ersten Stapelrahmen, der deine eigene Klasse nennt. Bei einem fehlgeschlagenen Integer.parseInt können Bibliotheksrahmen vor dem Aufruf in deinem Code stehen.

Der Stacktrace folgt dem Aufrufstapel, der Kette aktiver Methodenaufrufe. Er zeigt dir, wo du suchen solltest, aber der fehlerhafte Wert kann früher entstanden sein. Hier erkennt die Division das Problem; der Aufrufer hat das leere Array übergeben. Entscheide, ob eine leere Eingabe vor der Berechnung eines Mittelwerts abgelehnt oder behandelt werden soll.

Untersuche das Ausnahmeobjekt

e.getMessage() gibt die Meldung zurück und kann null zurückgeben. e.toString() enthält den Klassennamen und, falls vorhanden, die Meldung. e.printStackTrace() gibt den Stacktrace auf dem Standardfehlerstrom aus. Ein Abschnitt Caused by: zeigt eine frühere Ausnahme, die innerhalb einer Hülle erhalten blieb.

Von der JVM erzeugte NullPointerException-Meldungen benennen normalerweise den Ausdruck, der null ist. Eine ausdrücklich erzeugte Ausnahme kann stattdessen eine eigene Meldung oder keine Meldung haben. Verfolge die Referenz zurück bis zu der Stelle, an der sie ein Objekt hätte erhalten sollen.

Eine unbehandelte Ausnahme, die main verlässt, beendet den Hauptthread; bei einem Programm mit nur einem Thread endet damit das Programm. Behebe Programmfehler wie falsche Indizes im Code. Plane eine sinnvolle Fortsetzung für erwartete externe Probleme wie eine fehlende Datei oder eine ungültige Benutzereingabe.

Für Ausnahmeklassen gelten die Vererbungsregeln, die du bereits kennst. Ein geworfenes Objekt einer Unterklasse gehört auch zu seiner Oberklasse. Das erklärt sowohl Javas Ausnahmekategorien als auch, wie eine Ausnahmebehandlung dazu passt.

Verfolge die Hierarchie

Nur Objekte von Throwable oder seinen Unterklassen können geworfen werden. Darunter liegen zwei Hauptzweige:

Throwable
  Error
    OutOfMemoryError
    StackOverflowError
  Exception
    RuntimeException
      IllegalArgumentException
        NumberFormatException
      NullPointerException
      IndexOutOfBoundsException
        ArrayIndexOutOfBoundsException
    IOException
      FileNotFoundException
      NoSuchFileException

Error beschreibt schwerwiegende Fehler der Laufzeitumgebung. Eine gewöhnliche Anwendung sollte nicht versuchen, nach einem ausgeschöpften Heap oder einem durch endlose Rekursion erschöpften Stapel fortzufahren. Exception beschreibt Probleme, die eine Anwendung behandeln kann, einschließlich des RuntimeException-Zweigs.

Beide Arten werden zur Laufzeit geworfen. Das Wort „geprüft“ beschreibt die Prüfung deiner Behandlung durch den Compiler und keinen früheren Zeitpunkt, zu dem der Fehler auftritt. Ungeprüft bedeutet auch nicht harmlos: Eine unbehandelte Nullreferenz kann ein Programm stoppen.

Wende Abfangen oder Deklarieren an

Das Lesen einer Datei kann auch bei korrektem Code fehlschlagen. Eine Hilfsmethode kann die Entscheidung ihrem Aufrufer überlassen:

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.List;

class Names {
    static List<String> load(Path file) throws IOException {
        return Files.readAllLines(file);
    }
}

Files.readAllLines kann die geprüfte IOException werfen. Die Deklaration gibt diese Möglichkeit an den Aufrufer weiter, der sie ebenfalls abfangen oder deklarieren muss. Wird throws IOException entfernt, ohne eine Ausnahmebehandlung hinzuzufügen, lässt sich die Hilfsmethode nicht kompilieren. Für eine Methode, die Integer.parseInt verwendet, besteht keine vergleichbare Pflicht durch den Compiler, weil NumberFormatException ungeprüft ist.

Geprüfte Ausnahmen beschreiben oft Umstände, auf die sich ein Aufrufer einstellen kann, etwa das Verschwinden einer Datei. Laufzeitausnahmen weisen oft auf Programmfehler oder ungültige Argumente hin. Das sind hilfreiche Gründe für den Entwurf, aber die Oberklassenkette bestimmt die Kategorie. Eine eigene Klasse, die RuntimeException erweitert, bleibt ungeprüft, selbst wenn ein Aufrufer das Programm sinnvoll fortsetzen könnte.

Ordne Ausnahmebehandlungen anhand der Vererbung zu

catch (IOException e) kann eine FileNotFoundException oder NoSuchFileException behandeln. catch (Exception e) fängt auch Laufzeitausnahmen ab; es kann einen Programmfehler in eine irreführende Eingabemeldung verwandeln. catch (Throwable e) erreicht auch den Error-Zweig und ist für eine gewöhnliche Fortsetzung selten angebracht.

Um eine unbekannte Klasse einzuordnen, verfolge ihre Vererbung in der API-Dokumentation nach oben. InputMismatchException erweitert NoSuchElementException, das RuntimeException erweitert, und ist daher ungeprüft. InterruptedException erweitert Exception außerhalb des Laufzeitzweigs und ist daher geprüft. Einen ungeprüften Typ in einer throws-Klausel zu deklarieren, ist erlaubt, ändert aber seine Kategorie nicht.

Ein try-Block markiert Arbeit, die fehlschlagen kann. Ein passender catch-Block gibt dem Programm eine sinnvolle nächste Handlung vor, etwa nach einem anderen Wert zu fragen. Das Behandeln der Ausnahme wiederholt die fehlgeschlagene Anweisung nicht von selbst.

Verfolge die Zweige

System.out.println("A");
try {
    System.out.println("B");
    int value = Integer.parseInt("4x");
    System.out.println("C");
} catch (NumberFormatException e) {
    System.out.println("D: " + e.getMessage());
}
System.out.println("E");

Die Ausgabe besteht aus A, B, D: For input string: "4x" und E, jeweils in einer eigenen Zeile. Die Umwandlung schlägt fehl, daher überspringt Java C und führt die passende Ausnahmebehandlung aus. Endet diese normal, wird die Ausführung nach der gesamten Anweisung fortgesetzt. Gelingt die Umwandlung, wird die Ausnahmebehandlung übersprungen. Wirft der Block eine ArithmeticException, passt diese Ausnahmebehandlung nicht; die Ausnahme wird weitergegeben.

Wiederhole den Versuch mit neuer Eingabe

Lies vor der Umwandlung eine ganze Zeile. Die folgende Schleife akzeptiert eine Ganzzahl und behandelt das Ende der Tastatureingabe, indem sie meldet, dass kein Wert eingegeben wurde:

import java.util.Scanner;

class WholeNumbers {
    static int readWholeNumber(Scanner in) {
        while (in.hasNextLine()) {
            String line = in.nextLine();
            try {
                return Integer.parseInt(line.trim());
            } catch (NumberFormatException e) {
                System.out.println("Please enter a whole number.");
            }
        }
        throw new IllegalStateException("No number supplied");
    }
}

Bei den Eingaben „twenty“ und „20“ gibt die Ausnahmebehandlung einmal eine Meldung aus, die Schleife liest eine neue Zeile und die Methode gibt 20 zurück. trim() entfernt umgebenden Leerraum: Integer.parseInt(" 20") schlägt andernfalls fehl. Die Umwandlung akzeptiert ein optionales Vorzeichen und Ziffern, die eine Ganzzahl im Wertebereich darstellen.

Ein tokenbasierter Scanner benötigt eine andere Lösung. Trifft nextInt() auf „ten“, lässt die InputMismatchException dieses Token ungelesen. Wird die Ausnahme abgefangen und nextInt() erneut aufgerufen, wiederholt sich der Fehler endlos. Lies das fehlerhafte Token mit next() ein oder verwirf die Zeile mit nextLine(), bevor du es erneut versuchst. hasNextInt() kann ein Token vor der Umwandlung prüfen.

Halte den Zustand nach der Behandlung verwendbar

Eine innerhalb von try deklarierte Variable existiert nur in diesem Block. Benötigt späterer Code das Ergebnis, deklariere sie außerhalb und weise ihr auf jedem Pfad, der fortgesetzt wird, einen gültigen Wert zu:

int quantity;
try {
    quantity = Integer.parseInt("bad");
} catch (NumberFormatException e) {
    quantity = 0;
}
System.out.println(quantity);

Null ist hier nur dann angemessen, wenn das Programm sie als gültigen Ersatzwert definiert. Bleibt quantity in der Ausnahmebehandlung ohne Zuweisung, entsteht beim Kompilieren ein Fehler wegen fehlender eindeutiger Zuweisung.

Fange den spezifischen Typ ab, den du behandeln kannst. Eine leere Ausnahmebehandlung verschweigt das Problem; ein allgemeines catch (Exception e) kann einen Nullreferenzfehler als fehlerhafte Zahl ausgeben. Eine sinnvolle Fortsetzung sollte erneut fragen, ein Element überspringen, einen gültigen Standardwert wählen, den Fehler melden oder eine aussagekräftige Ausnahme weitergeben. Prüfe bei einfachen vorhersehbaren Grenzen zuerst: index >= 0 && index < list.size() verhindert sowohl negative als auch zu große Listenindizes.

Eine Datei kann fehlen, nicht lesbar oder voller fehlerhaft formatierter Datensätze sein. Diese Fehler erfordern unterschiedliche Reaktionen. Mehrere Ausnahmebehandlungen erlauben es einem try, sie zu unterscheiden, während die Position des Blocks entscheidet, wie viel Arbeit bei einem Fehler abgebrochen wird.

Setze spezifische Ausnahmebehandlungen zuerst

Java prüft Ausnahmebehandlungen von oben nach unten und führt die erste passende aus. Es führt für dieselbe Ausnahme keine späteren Ausnahmebehandlungen mehr aus.

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.NoSuchFileException;
import java.nio.file.Path;

class FirstCount {
    static void show(Path file) {
        try {
            int count = Integer.parseInt(Files.readString(file).trim());
            System.out.println(count);
        } catch (NoSuchFileException e) {
            System.out.println("File not found: " + file.toAbsolutePath());
        } catch (IOException e) {
            System.out.println("Could not read: " + file.toAbsolutePath());
        } catch (NumberFormatException e) {
            System.out.println("The file must contain one whole number.");
        }
    }
}

NoSuchFileException erweitert IOException und muss daher zuerst kommen. Eine umgekehrte Reihenfolge macht die spezifische Ausnahmebehandlung unerreichbar und verhindert die Kompilierung. Die Umwandlungsausnahme ist nicht durch Vererbung mit IOException verbunden, daher können diese beiden Ausnahmebehandlungen in beliebiger Reihenfolge stehen.

Eine Ausnahmebehandlung für eine geprüfte Ausnahme muss außerdem für die geschützte Arbeit relevant sein. Wird IOException nur um int count = 5; herum abgefangen, wird das abgelehnt, weil dieser Block die Ausnahme nicht werfen kann. Diese Einschränkung gilt nicht in gleicher Weise für ungeprüfte Typen oder die allgemeinen Typen Exception und Throwable.

Verwende eine gemeinsame Ausnahmebehandlung für dieselbe Reaktion

Ein Multi-Catch verbindet nicht durch Vererbung zusammenhängende Ausnahmetypen mit |:

try {
    String[] parts = "Ana".split(",");
    int age = Integer.parseInt(parts[1]);
    System.out.println(age);
} catch (NumberFormatException | ArrayIndexOutOfBoundsException e) {
    System.out.println("Invalid record: " + e.getMessage());
}

Hier löst das fehlende zweite Feld die Indexausnahme aus. Ein vorhandenes, aber nicht numerisches Feld würde die Umwandlungsausnahme auslösen, und beide würden dieselbe Reaktion erhalten. Der Multi-Catch-Parameter ist implizit final. Die Alternativen dürfen nicht eine Unterklasse und ihre Oberklasse sein: FileNotFoundException | IOException ist ungültig, weil IOException bereits beide abdeckt.

Entscheide, was bei einem Fehler übersprungen werden soll

Betrachte die Texte „3“, „x“ und „5“. Liegt ein try um die gesamte Schleife, stoppt die Verarbeitung bei „x“ und die bisherige Summe ist 3. Setze das try in die Schleife, um jedes Element einzeln zu behandeln:

int sum = 0;
for (String text : new String[] {"3", "x", "5"}) {
    try {
        sum += Integer.parseInt(text);
    } catch (NumberFormatException e) {
        System.out.println("Skipped: " + text);
    }
}
System.out.println(sum);

Dies gibt Skipped: x und dann 8 aus. Die Schleife läuft weiter, weil ihr Rumpf den Fehler dieses Datensatzes behandelt hat. Bei verschachtelten Ausnahmebehandlungen beginnt die Suche im innersten geschützten Block und verläuft nach außen; eine nicht passende innere Ausnahmebehandlung lässt einer äußeren eine Chance. Wähle die kleinste Arbeitseinheit, die gemeinsam fehlschlagen soll: einen Datensatz bei fehlerhaften Daten, den Dateivorgang bei einem Lesefehler.

Manche Arbeit muss erledigt werden, ob eine Operation gelingt oder fehlschlägt. Ein finally-Block wird ausgeführt, wenn der Kontrollfluss seine try-Anweisung verlässt, auch wenn eine Ausnahme weitergegeben wird oder eine Methode zurückkehrt.

Verfolge eine nicht passende Ausnahme

try {
    System.out.println("1");
    int[] values = new int[2];
    values[2] = 7;
    System.out.println("2");
} catch (NumberFormatException e) {
    System.out.println("3");
} finally {
    System.out.println("4");
}
System.out.println("5");

Nur 1 und 4 werden ausgegeben, bevor die ArrayIndexOutOfBoundsException weitergegeben wird. Index 2 liegt außerhalb des Arrays mit zwei Elementen. Die Ausnahmebehandlung passt nicht, aber finally wird trotzdem ausgeführt. Die Anweisung, die 5 ausgibt, steht außerhalb des Aufräumblocks und wird daher durch die weitergegebene Ausnahme übersprungen.

Wirft die geschützte Arbeit nach der Ausgabe von 1 stattdessen eine passende NumberFormatException, gibt die Ausnahmebehandlung 3 aus, die Aufräumarbeiten geben 4 aus und die Ausführung wird bei 5 fortgesetzt. Auf einem erfolgreichen Pfad wird keine Ausnahmebehandlung ausgeführt, die Aufräumarbeiten aber trotzdem.

Rückgabewerte werden vor den Aufräumarbeiten vorbereitet

class Cleanup {
    static int result() {
        try {
            return 1;
        } finally {
            System.out.println("cleanup");
        }
    }
}

Der Rückgabeausdruck wird zuerst ausgewertet. Java gibt dann cleanup aus und der Aufrufer erhält 1. Auch ein break oder continue, das einen geschützten Bereich verlässt, führt dessen Aufräumarbeiten aus, bevor die Änderung des Kontrollflusses wirksam wird.

Verwende kein return in finally. Ein dortiges return 2; würde den ausstehenden Rückgabewert ersetzen und könnte sogar eine ausstehende Ausnahme verwerfen. Eine bei den Aufräumarbeiten geworfene Ausnahme kann ebenso den ursprünglichen Fehler ersetzen. Die Aufräumarbeiten sollten kein zweites konkurrierendes Ergebnis erzeugen. Die Compileroption -Xlint:finally warnt, wenn ein finally-Block nicht normal enden kann.

Schließe ein Objekt nur, wenn es geöffnet wurde

Das ältere manuelle Muster benötigt eine Variable, die für den Aufräumblock sichtbar ist:

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Path;
import java.util.Scanner;

class ManualRead {
    static void firstLine(Path file) throws IOException {
        Scanner sc = null;
        try {
            sc = new Scanner(file, StandardCharsets.UTF_8);
            if (sc.hasNextLine()) System.out.println(sc.nextLine());
            if (sc.ioException() != null) throw sc.ioException();
        } finally {
            if (sc != null) sc.close();
        }
    }
}

Schlägt das Öffnen fehl, ist sc weiterhin null, sodass die Prüfung verhindert, dass die Aufräumarbeiten eine neue Nullreferenzausnahme werfen. Für schließbare Objekte erspart try-with-resources diese Verwaltungsarbeit und geht sicherer mit konkurrierenden Fehlern um.

finally ist keine Garantie gegen das Anhalten der Maschine. System.exit beendet die JVM, ohne diese Aufräumarbeiten auszuführen; ein Absturz oder Stromausfall verhindert sie ebenfalls. Eine Endlosschleife, die den Block nie verlässt, erreicht auch dessen finally nie.

Deine Methoden können ungültige Anfragen ablehnen, bevor sie ein Objekt verändern. Wähle eine Ausnahme, die das Problem benennt und dem Aufrufer eine Reaktion ermöglicht.

Wirf jetzt ein Objekt

class Percentage {
    private int value;

    public void setPercentage(int value) {
        if (value < 0 || value > 100) {
            throw new IllegalArgumentException(
                "percentage must be 0 to 100, was " + value);
        }
        this.value = value;
    }
}

Der Aufruf setPercentage(120) wirft eine Ausnahme mit der Meldung percentage must be 0 to 100, was 120. Die Zuweisung wurde noch nicht ausgeführt, sodass das Feld seinen bisherigen Wert behält. Das ist das Fail-fast-Prinzip: Melde die ungültige Anfrage an der Stelle, an der du sie erklären kannst. Dieselbe Prüfung in einem Konstruktor verhindert, dass ein ungültiges Objekt zurückgegeben wird.

throw benötigt ein Ausnahmeobjekt, wie in throw new IllegalArgumentException("bad quantity");. Ein Klassenname allein ist kein Objekt. Eine gewöhnliche Anweisung direkt nach einem bedingungslosen throw im selben Block ist unerreichbar.

Objects.requireNonNull(name, "name must not be null") aus java.util.Objects ist eine praktische null-Prüfung. Wenn eine bereits versandte Bestellung einen weiteren Artikel ablehnt, ist das ein Zustandsproblem; eine negative Artikelmenge ist ein Argumentproblem.

Deklariere, was die Methode verlassen kann

Eine Hilfsmethode zum Lesen von Dateien kann ihre geprüfte Ausnahme deklarieren:

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.List;

class NameLoader {
    static List<String> loadNames(Path file) throws IOException {
        return Files.readAllLines(file);
    }
}

throw ist eine ausführbare Anweisung. throws gehört zur Methodendeklaration und teilt Aufrufern mit, um welche geprüften Ausnahmen sie sich kümmern müssen. Es fängt weder einen Fehler ab noch sorgt es dafür, dass die Methode danach fortfährt. Jeder Aufrufer muss IOException abfangen oder seinerseits deklarieren. Ein catch-Block kann dasselbe Objekt auch mit throw e; erneut werfen.

Fange eine Ausnahme dort ab, wo eine sinnvolle Reaktion möglich ist. Eine Hilfsmethode kann den Benutzer normalerweise nicht auffordern, eine andere Datei zu wählen, main dagegen schon. Würde sie „Fehler“ ausgeben und eine leere Liste zurückgeben, ließe sich eine fehlende Datei nicht von einer tatsächlich leeren unterscheiden. Bei einem kleinen Experiment kann main mit throws IOException deklariert werden; ein fertiges Programm behandelt erwartete Fehler mit hilfreichen Meldungen. Ungeprüfte Typen dürfen zur Dokumentation deklariert werden, obwohl der Compiler es nicht verlangt.

Beachte den geerbten Vertrag

Deklariert ein Interface read() throws IOException, darf eine überschreibende Methode IOException, eine spezifischere geprüfte Unterklasse oder keine geprüfte Ausnahme deklarieren. Sie darf die Deklaration nicht auf Exception erweitern. Ungeprüfte Typen darf sie deklarieren. Eine Überschreibung von Object.toString() kann keine IOException hinzufügen, da die geerbte Methode keine geprüften Ausnahmen deklariert. Bei Aufrufen über den Interface-Typ muss die deklarierte IOException weiterhin behandelt werden, selbst wenn eine Implementierung keine deklariert.

Eine Standardausnahme genügt oft. Erstelle eine eigene Klasse, wenn Aufrufer ein programmspezifisches Problem wie einen unzureichenden Lagerbestand oder einen fehlerhaft formatierten Datensatz erkennen und anders darauf reagieren müssen.

Wähle die Oberklasse bewusst

Das Erweitern von Exception erzeugt eine geprüfte Ausnahme. Das Erweitern von RuntimeException erzeugt eine ungeprüfte Ausnahme. Wähle die geprüfte Variante, wenn Aufrufer mit einem behebbaren fachlichen Fehler rechnen sollen; wähle die ungeprüfte Variante bei falscher Verwendung oder einem Programmierfehler.

class OutOfStockException extends Exception {
    public OutOfStockException(String message) {
        super(message);
    }
}

super(message) speichert die Meldung in der geerbten Ausnahmeimplementierung, sodass getMessage() sie zurückgibt. Der Klassenname endet üblicherweise auf Exception. Zusätzliche Felder und Getter können strukturierte Angaben wie angeforderte und verfügbare Mengen bereitstellen.

Lass den Lagerbestand nach einem Fehler unverändert

import java.util.HashMap;

class Inventory {
    private final HashMap<String, Integer> stock = new HashMap<>();

    Inventory() {
        stock.put("pens", 12);
    }

    void remove(String item, int quantity) throws OutOfStockException {
        if (quantity <= 0) {
            throw new IllegalArgumentException("quantity must be positive");
        }
        int available = stock.getOrDefault(item, 0);
        if (quantity > available) {
            throw new OutOfStockException("Requested " + quantity
                + " of " + item + ", only " + available + " in stock");
        }
        stock.put(item, available - quantity);
    }
}

Bei einem Anfangsbestand von 12 Stiften bleiben nach der Entnahme von 5 noch 7. Eine spätere Anfrage nach 10 wirft eine Ausnahme, und es bleiben 7, weil die Aktualisierung erst nach allen Prüfungen erfolgt. Der Aufrufer muss die geprüfte Lagerbestandsausnahme behandeln oder deklarieren; die Ausnahme für eine ungültige Menge ist ungeprüft. Ein Programm, das eine eigene Reaktion auf unbekannte Artikel benötigt, könnte eine verwandte UnknownItemException verwenden, wobei beide fachlichen Typen unter einer Basisklasse InventoryException stehen.

Verpacke das Problem, ohne es zu verlieren

Eine Methode zum Parsen kann einen tieferliegenden Umwandlungsfehler in einen Datensatzfehler umwandeln:

class InvalidRecordException extends Exception {
    public InvalidRecordException(String message) {
        super(message);
    }
    public InvalidRecordException(String message, Throwable cause) {
        super(message, cause);
    }
}

Innerhalb der Methode zum Parsen kann eine Ausnahmebehandlung Folgendes tun:

catch (NumberFormatException e) {
    throw new InvalidRecordException(
        "Line 3: quantity is not a number: x", e);
}

Die umschließende Ausnahme gibt dem Aufrufer eine aussagekräftige Kategorie und eine Zeilennummer. Ihr getCause() gibt die ursprüngliche NumberFormatException zurück und ein ausgegebener Stacktrace enthält weiterhin einen Abschnitt Caused by:. Wird eine neue Ausnahme nur mit der alten Meldung erzeugt, gehen das ursprüngliche Objekt und sein Stacktrace verloren.

java.io.UncheckedIOException ist eine vorgefertigte ungeprüfte Hülle speziell für IOException. Ihre Konstruktoren akzeptieren die Ursache und optional eine Meldung. Sie kann einen Dateifehler durch eine überschreibende Methode weitergeben, die keine geprüfte Ausnahme deklarieren darf. Das Verpacken ändert den Typ, den der Aufrufer sieht; es behebt das Dateiproblem nicht. Drücke gewöhnliche Schleifenentscheidungen mit Bedingungen und break aus, ohne für den normalen Ablauf Ausnahmen zu erfinden.

Eine Datei speichert Bytes, während dein Programm mit Zeichen und Zahlen arbeitet. Für einen erfolgreichen Lesevorgang brauchst du den richtigen Speicherort, die richtige Zeichenkodierung und eine klare Konvention für Zeilen und Zahlen als Text.

Finde den tatsächlichen Speicherort

Ein relativer Pfad beginnt im Arbeitsverzeichnis des Programms. Er beginnt nicht im Ordner mit dem Quellcode. Ein absoluter Pfad beginnt im Wurzelverzeichnis des Dateisystems, etwa /home/ana/data/scores.txt, oder im Stammverzeichnis eines Laufwerks unter Windows.

Path file = Path.of("data", "scores.txt");
System.out.println(System.getProperty("user.dir"));
System.out.println(file.toAbsolutePath());
System.out.println(file.getFileName());

Importiere java.nio.file.Path. Das Erzeugen dieses Path öffnet nichts und prüft nicht, ob etwas existiert. toAbsolutePath() zeigt, wo Java suchen wird, und getFileName() liefert scores.txt. Eine IDE verwendet häufig den Projektordner als Arbeitsverzeichnis. Schrägstriche in "data/scores.txt" funktionieren unter Windows, Linux und macOS. In einem Windows-Pfadliteral mit umgekehrten Schrägstrichen müssen diese als Escape-Sequenz geschrieben werden, wie in "C:\\data\\scores.txt". Auch das ältere java.io.File stellt einen Speicherort dar; wandle mit toPath() oder toFile() um.

Ordne Bytes den Zeichen zu

UTF-8 kodiert jedes Unicode-Zeichen. Einfache lateinische Zeichen benötigen ein Byte; andere benötigen zwei bis vier. Der Text „café“ enthält vier Zeichen, aber fünf UTF-8-Bytes, weil „é“ zwei benötigt. Werden diese Bytes als ISO-8859-1 gelesen, kann „café“ entstehen. Verwende die Kodierung, mit der der Text geschrieben wurde.

Die Textmethoden von Files verwenden standardmäßig UTF-8. Klassen wie FileWriter und ein ohne Zeichensatz geöffneter Scanner verwenden den Standardzeichensatz, der seit Java 18 UTF-8 ist; bei älteren Installationen kann er abweichen. StandardCharsets.UTF_8 aus java.nio.charset legt die Wahl ausdrücklich fest. Ungültige Bytes beim Lesen mit Files.readAllLines erzeugen eine MalformedInputException, eine Unterklasse von IOException.

Lies Zeilen ohne zurückbleibende Zeilenenden

Mit einem Abschlusszeichen nach jeder Zeile benötigen „a“ und „b“ vier Bytes mit LF-Enden und sechs mit CRLF-Enden. BufferedReader.readLine(), Files.readAllLines und Scanner.nextLine() entfernen erkannte Zeilenenden. Wird ein vollständiger String mit split("\n") aufgeteilt, bleibt das Windows-\r stehen, sodass die Umwandlung von "12\r" mit parseInt fehlschlägt. Bevorzuge Methoden zum zeilenweisen Lesen oder entferne den umgebenden Leerraum. System.lineSeparator() und der Formatspezifizierer %n erzeugen das Zeilenende des aktuellen Systems.

Halte Zahlen in Dateien einheitlich

Integer.parseInt akzeptiert Ganzzahlen als Text ohne Dezimaltrennzeichen. Double.parseDouble("3.5") akzeptiert einen Punkt; Double.parseDouble("3,5") schlägt fehl. Diese Methoden zum Parsen ignorieren das Gebietsschema. Numerische Scanner-Methoden und gewöhnliche Dezimalformatierung richten sich nach dem Gebietsschema, sodass deutsche oder niederländische Einstellungen „3,5“ erwarten und „3,50“ erzeugen können. Verwende scanner.useLocale(Locale.ROOT) und String.format(Locale.ROOT, "%.2f", value) für Daten mit Dezimalpunkt; importiere java.util.Locale.

Fehlende Speicherorte führen häufig zu einer NoSuchFileException bei Files oder Scanner(Path), während ältere Konstruktoren mit Dateinamen eine FileNotFoundException ergeben können. Fehlende Berechtigungen können zu einer AccessDeniedException führen. Dies sind geprüfte Ein- und Ausgabefehler: Ein korrekter Pfadausdruck allein kann sie nicht verhindern.

Eine offene Datei belegt eine Ressource des Betriebssystems. Das Schließen gibt sie frei und leert den Puffer eines Writers mit ausstehender Ausgabe. Ein vergessenes Schließen kann die erlaubte Anzahl offener Dateien ausschöpfen, gepufferten Text verlieren lassen oder verhindern, dass ein anderes Programm die Datei ändert.

Deklariere Ressourcen im try-Kopf

import java.io.BufferedReader;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;

class Lines {
    static void show(Path file) throws IOException {
        try (BufferedReader in =
                Files.newBufferedReader(file, StandardCharsets.UTF_8)) {
            String line;
            while ((line = in.readLine()) != null) {
                System.out.println(line);
            }
        }
    }
}

Der Kopf öffnet den Reader. Der Rumpf verwendet ihn und Java schließt ihn, wenn der Rumpf normal endet, zurückkehrt oder eine Ausnahme wirft. Ein eigenes finally ist nicht nötig. Hier gibt es keine Ausnahmebehandlung, sodass jede geprüfte Ausnahme weiterhin über throws IOException an den Aufrufer weitergegeben wird.

Eine Ressource muss AutoCloseable implementieren. Dieses Interface deklariert close() und erlaubt Exception; sein Unterinterface Closeable schränkt die deklarierte geprüfte Ausnahme auf IOException ein. Reader, Writer und Scanner erfüllen diese Bedingung. Ein String tut das nicht. Variablen im Kopf sind implizit final und stehen im Rumpf zur Verfügung, nicht aber in den catch- oder finally-Blöcken dieser Anweisung. Java 9 und neuer erlauben auch eine vorhandene finale oder effektiv finale Variable: try (in) { ... }.

Schließe in umgekehrter Reihenfolge

Trenne Ressourcen durch Semikolons:

try (BufferedReader in = Files.newBufferedReader(source);
     java.io.BufferedWriter out = Files.newBufferedWriter(target)) {
    String line;
    while ((line = in.readLine()) != null) {
        out.write(line);
        out.newLine();
    }
}

Dies ist ein Block innerhalb einer Methode, die IOException deklariert, mit unterschiedlichen Pfaden source und target. Java öffnet zuerst in, dann out und schließt out vor in. Schlägt das Öffnen von out fehl, wird der bereits geöffnete Reader trotzdem geschlossen. Ein Writer für den Eingabepfad würde diese Eingabe beim Öffnen leeren, daher müssen die Pfade für diese direkte Kopie verschieden sein.

Ressourcen werden vor den catch- und finally-Klauseln derselben Anweisung geschlossen. Diese Ausnahmebehandlungen können Fehler beim Öffnen, Verwenden oder Schließen der Ressourcen erhalten.

Halte den Hauptfehler sichtbar

Angenommen, der Rumpf wirft eine Datensatzausnahme und anschließend wirft das Schließen des Readers eine IOException. Try-with-resources gibt die Ausnahme aus dem Rumpf weiter und fügt den Fehler beim Schließen als unterdrückt hinzu. getSuppressed() ruft ihn ab und der Stacktrace gibt einen Abschnitt Suppressed: aus. Der ursprüngliche Fehler aus dem Rumpf bleibt sichtbar. Ist der Rumpf erfolgreich und schlägt nur das Schließen fehl, wird die Ausnahme beim Schließen normal weitergegeben.

Bei mehreren Fehlern während des Schließens versucht Java weiterhin, die übrigen Ressourcen zu schließen. Ein einfaches finally { resource.close(); } kann dagegen einen ausstehenden Fehler aus dem Rumpf durch einen Fehler beim Aufräumen ersetzen.

Verwende dieses Muster für Dateiressourcen, die deinem Code gehören. Das Schließen eines Scanners für System.in schließt auch die Tastatureingabe des Programms und verhindert spätere Lesezugriffe. Die Verantwortung für die gemeinsam genutzte Standardeingabe sollte beim Programm liegen, statt sie in einer Hilfsmethode zu schließen.

Das Lesen liefert dir Text. Das Parsen gibt diesem Text eine Bedeutung: eine Anzahl, ein Alter oder ein Objekt. Halte diese beiden Vorgänge getrennt, damit ein fehlerhafter Datensatz nicht wie ein fehlgeschlagenes Lesen der Datei aussieht.

Entscheide, wie viel im Speicher bleiben soll

Importiere java.nio.file.Files und Path sowie die verwendeten Reader- oder Collection-Typen. Die Textmethoden von Files verwenden standardmäßig UTF-8. Ein BufferedReader gehört in try-with-resources und meldet Lesefehler mit IOException. Das Lesen einzelner Zeilen vermeidet es, die gesamte Eingabe im Speicher zu halten, sofern die Verarbeitung nicht anschließend alle Datensätze speichert.

Auch ein Scanner muss geschlossen werden und benötigt eine zusätzliche Fehlerprüfung:

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Path;
import java.util.Scanner;

class ScanFile {
    static void show(Path file) throws IOException {
        try (Scanner sc = new Scanner(file, StandardCharsets.UTF_8)) {
            while (sc.hasNextLine()) {
                System.out.println(sc.nextLine());
            }
            if (sc.ioException() != null) throw sc.ioException();
        }
    }
}

Das Öffnen kann direkt eine Ausnahme werfen. Während des Lesens behandelt Scanner einen zugrunde liegenden Ein- oder Ausgabefehler als Ende der Eingabe und speichert ihn; ioException() macht ihn zugänglich. Ohne diese abschließende Prüfung kann ein unvollständiger Lesevorgang erfolgreich erscheinen.

Zähle die tatsächlichen Zeilen und parse sie dann

Erhöhe bei den Eingabezeilen „12“, „15“, „abc“, einer leeren Zeile und „9“ die Zeilennummer, bevor du entscheidest, ob du eine leere Zeile überspringst. Wandle jede nicht leere Zeile innerhalb eines eigenen try mit Integer.parseInt(line.trim()) um. Melde „Line 3: not a number: abc“ und fahre fort. Die gültige Summe ist 36 und die Anzahl 3, was den Mittelwert 12,0 ergibt. Berechne (double) sum / count, um einen möglichen Nachkommateil zu erhalten, und prüfe zuerst, dass die Anzahl nicht null ist.

Prüfe Felder vor dem Zugriff über Indizes

Einfache kommagetrennte Daten können zu Objekten werden. Hier ist die erste Zeile eine erforderliche Kopfzeile; jeder weitere Datensatz hat einen nicht leeren Namen und ein ganzzahliges Alter:

String[] parts = line.split(",", -1);
if (parts.length != 2 || parts[0].isBlank() || parts[1].isBlank()) {
    System.out.println("Line " + lineNumber + ": expected name and age");
    continue;
}
try {
    int age = Integer.parseInt(parts[1].trim());
    people.add(new Person(parts[0].trim(), age));
} catch (NumberFormatException e) {
    System.out.println("Line " + lineNumber + ": invalid age");
}

Dieses Fragment eines Schleifenrumpfs setzt line, lineNumber, eine List<Person> namens people und einen Konstruktor Person(String, int) voraus. Überspringe die Kopfzeile „name,age“ vor diesem Parsen; andernfalls schlägt die numerische Umwandlung von „age“ fehl. Die Datensätze „Ana,34“, „Ben,29“ und „Chen,41“ ergeben zusammen 104 Jahre und im Durchschnitt etwa 34,67.

Ein einfaches split(",") verwirft leere Felder am Ende: „Eve,“ ergibt nur einen Teil. Die Begrenzung -1 erhält das leere zweite Feld, sodass die Validierung es melden kann. Prüfe immer die Länge vor parts[1]. Das Aufteilen allein verarbeitet keine Kommas innerhalb von Anführungszeichen, etwa im Namen in „"Smith, Ana",34“; vollständiges CSV benötigt einen CSV-Parser.

Das Öffnen einer Ausgabedatei kann sie sofort verändern. Entscheide dich vor dem Öffnen des Writers für Ersetzen oder Anhängen und schließe ihn anschließend, damit gepufferte Ausgabe nicht im Speicher zurückbleibt.

Ersetzen oder anhängen

Files.writeString(path, text) schreibt einen String. Files.write(path, lines) schreibt ein durchlaufbares Objekt von Zeilen und fügt nach jeder Zeile, auch der letzten, das Zeilentrennzeichen des Systems ein. Mit ihren Standardoptionen erstellen beide eine fehlende Datei und leeren eine vorhandene.

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.StandardOpenOption;

class RunLog {
    static void recordStart(Path log) throws IOException {
        Files.writeString(log, "started" + System.lineSeparator(),
            StandardCharsets.UTF_8,
            StandardOpenOption.CREATE, StandardOpenOption.APPEND);
    }
}

CREATE erlaubt eine neue Datei; APPEND erhält den alten Inhalt und fügt am Ende hinzu. APPEND allein schlägt fehl, wenn die Datei fehlt. Das Anhängen fügt vor deinem Text kein fehlendes Trennzeichen ein: Endet eine vorhandene Datei mitten in einer Zeile, setzen die nächsten Zeichen diese Zeile fort.

Der ältere FileWriter hat ein Flag zum Anhängen: new FileWriter("log.txt", StandardCharsets.UTF_8, true). Ohne Anhängen leert auch ein neuer FileWriter oder ein über den Dateinamen geöffneter PrintWriter eine vorhandene Datei. Öffne niemals einen Writer, der den Inhalt ersetzt, für eine Eingabe, die du noch lesen musst.

Wähle einen Writer und beachte Fehler

BufferedWriter unterstützt write und newLine() und meldet Schreibfehler als geprüfte Ausnahmen:

import java.io.BufferedWriter;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.Locale;

class ReportWriter {
    static void write(Path file) throws IOException {
        try (BufferedWriter out =
                Files.newBufferedWriter(file, StandardCharsets.UTF_8)) {
            out.write("Readings: 3");
            out.newLine();
            out.write(String.format(Locale.ROOT, "Average: %.2f", 3.0));
            out.newLine();
        }
    }
}

Die Datei hat zwei Zeilen: „Readings: 3“ und „Average: 3.00“. Locale.ROOT legt den Dezimalpunkt fest. newLine(), println und %n verwenden alle das Zeilenende der Plattform; ein literales \n schreibt auf jedem System LF.

Ein PrintWriter bietet die praktischen Methoden print, println und printf, aber diese Methoden speichern Ein- und Ausgabefehler, statt sie zu werfen. checkError() leert den Puffer und gibt das Fehlerflag zurück. Wenn du auch Fehler beim abschließenden Schließen prüfen willst, behalte den Zugriff auf den Writer und prüfe nach dem Schließen. Für Code, der Schreibfehler zuverlässig weitergeben muss, verwende BufferedWriter oder die Files-Methoden.

Vervollständige den Weg zurück zum Lesen

Writer puffern die Ausgabe. flush() sendet ausstehenden Text weiter; close() leert den Puffer und gibt die Datei frei. Try-with-resources stellt sicher, dass bei jedem Verlassen versucht wird zu schließen, kann aber einen erfolgreichen Schreibvorgang auf die Festplatte nicht garantieren.

Um eine Person zu speichern, schreibe den Namen, ein Komma und das ganzzahlige Alter und dann ein Zeilenende. Formatiere Dezimalzahlen mit Locale.ROOT, damit ein späteres Double.parseDouble sie lesen kann. Ein fehlendes übergeordnetes Verzeichnis wird beim Öffnen einer Datei nicht erstellt: Verwende Files.createDirectories(folder), wenn es erstellt werden soll, oder melde den Fehler. Ein Schreibvorgang kann nach dem Leeren der Datei oder einer teilweisen Ausgabe fehlschlagen; verwende eine temporäre Ausgabedatei und atomares Verschieben, wenn das Ziel geschützt werden muss.

Ein robustes Programm zur Dateiverarbeitung benötigt zwei Ebenen der Fehlerbehandlung. Ein fehlerhafter Datensatz kann übersprungen und gemeldet werden; ein Fehler beim Lesen oder Speichern der Datei stoppt die Aufgabe. Berechne ein vollständiges Ergebnis, bevor du auf das Ziel zugreifst.

Lesen, prüfen, berechnen, speichern

Das folgende vollständige Programm liest die optionale Kopfzeile „date,temperature“, gefolgt von einfachen Datensätzen mit zwei Feldern. Datumsangaben sind nicht leere Bezeichnungen; Temperaturen sind endliche Zahlen in Grad Celsius. Es überspringt und meldet fehlerhaft formatierte Datensätze einschließlich leerer Zeilen. Die verschachtelte geprüfte Ausnahme hält Datensatzprobleme von Dateiproblemen getrennt.

import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.nio.file.AtomicMoveNotSupportedException;
import java.nio.file.Files;
import java.nio.file.NoSuchFileException;
import java.nio.file.Path;
import java.nio.file.StandardCopyOption;
import java.util.List;
import java.util.Locale;

public class TemperatureReport {
    static class InvalidRecordException extends Exception {
        InvalidRecordException(String message) { super(message); }
        InvalidRecordException(String message, Throwable cause) {
            super(message, cause);
        }
    }

    static List<String> readLines(Path file) throws IOException {
        return Files.readAllLines(file, StandardCharsets.UTF_8);
    }

    static double parseTemperature(String line, int lineNumber)
            throws InvalidRecordException {
        String[] parts = line.split(",", -1);
        if (parts.length != 2 || parts[0].isBlank()
                || parts[1].isBlank()) {
            throw new InvalidRecordException("Line " + lineNumber
                + ": expected a date label and a temperature");
        }
        try {
            double value = Double.parseDouble(parts[1].trim());
            if (!Double.isFinite(value)) {
                throw new InvalidRecordException("Line " + lineNumber
                    + ": temperature must be finite");
            }
            return value;
        } catch (NumberFormatException e) {
            throw new InvalidRecordException("Line " + lineNumber
                + ": not a number: " + parts[1], e);
        }
    }

    static String summarize(List<String> lines) {
        int count = 0;
        int skipped = 0;
        double sum = 0;
        double min = Double.POSITIVE_INFINITY;
        double max = Double.NEGATIVE_INFINITY;
        for (int i = 0; i < lines.size(); i++) {
            String line = lines.get(i);
            if (i == 0 && line.equals("date,temperature")) continue;
            try {
                double value = parseTemperature(line, i + 1);
                sum += value;
                count++;
                min = Math.min(min, value);
                max = Math.max(max, value);
            } catch (InvalidRecordException e) {
                skipped++;
                System.err.println(e.getMessage());
            }
        }
        if (count == 0) {
            return String.format(Locale.ROOT,
                "No valid readings%nSkipped lines: %d%n", skipped);
        }
        return String.format(Locale.ROOT,
            "Valid readings: %d%nAverage (°C): %.2f%n"
                + "Minimum (°C): %.2f%nMaximum (°C): %.2f%n"
                + "Skipped lines: %d%n",
            count, sum / count, min, max, skipped);
    }

    static void writeSummary(Path file, String text) throws IOException {
        Path target = file.toAbsolutePath();
        Path temp = Files.createTempFile(target.getParent(), "report-", ".tmp");
        try {
            Files.writeString(temp, text, StandardCharsets.UTF_8);
            Files.move(temp, target, StandardCopyOption.ATOMIC_MOVE);
        } catch (IOException e) {
            try {
                Files.deleteIfExists(temp);
            } catch (IOException cleanup) {
                e.addSuppressed(cleanup);
            }
            throw e;
        }
    }

    public static void main(String[] args) {
        Path input = Path.of("readings.csv");
        Path output = Path.of("summary.txt");
        try {
            List<String> lines = readLines(input);
            String report = summarize(lines);
            writeSummary(output, report);
            System.out.println("Saved: " + output.toAbsolutePath());
        } catch (NoSuchFileException e) {
            System.err.println("File or folder not found: " + e.getFile());
        } catch (AtomicMoveNotSupportedException e) {
            System.err.println("Could not save atomically: "
                + output.toAbsolutePath());
        } catch (IOException e) {
            System.err.println("Could not process " + input.toAbsolutePath()
                + " or save " + output.toAbsolutePath() + ": " + e.getMessage());
        }
    }
}

Verfolge einen Programmlauf

Verwende diese fünf Eingabezeilen ohne Kopfzeile:

2026-03-01,4.5
2026-03-02,6.0
2026-03-03,abc
2026-03-04,-1.5
missing comma

Die Zeilen 1, 2 und 4 ergeben drei gültige Messwerte. Die Summe ist 9,0; der Mittelwert beträgt 3,00 °C, das Minimum -1,50 °C und das Maximum 6,00 °C. Die Zeilen 3 und 5 erzeugen Diagnosemeldungen und der Bericht verzeichnet zwei übersprungene Zeilen. Die Ausnahmebehandlung beim Parsen liegt innerhalb der Schleife, sodass nach jedem fehlerhaften Datensatz spätere Datensätze erreichbar bleiben. Werden Summen erst nach erfolgreichem Parsen aktualisiert, bleiben verworfene Werte außen vor.

Double.parseDouble akzeptiert besondere Strings wie „NaN“ und „Infinity“. Double.isFinite lehnt sie hier ab, weil sie nicht als gewöhnliche gemessene Temperaturen dienen können. Bei einer leeren Datei, einer Datei nur mit Kopfzeile oder ausschließlich ungültigen Datensätzen wird der Zweig für die Anzahl null vor der Division oder Verwendung des anfänglichen Minimums und Maximums erreicht.

Schütze das Ziel

Das Lesen und die Berechnung sind abgeschlossen, bevor das Speichern beginnt. Files.writeString öffnet und schließt seine Datei selbst, kann aber fehlschlagen, nachdem ein Teil geschrieben wurde. Das Programm schreibt daher in eine temporäre Datei im Zielordner, schließt sie und fordert ATOMIC_MOVE an. Das Verschieben macht das fertige Ergebnis, sofern unterstützt, als eine einzige Dateisystemoperation sichtbar.

Das atomare Ersetzen eines vorhandenen Ziels hängt von der Implementierung ab. Das Programm meldet ein nicht unterstütztes Verschieben oder Ersetzen und versucht es nie erneut mit einem nicht atomaren Verschieben. Ein Fehler beim Aufräumen wird der ursprünglichen Ausnahme hinzugefügt, statt sie zu ersetzen. Atomare Sichtbarkeit garantiert nicht, dass die Daten einen Stromausfall überstehen.

Eine vorherige Prüfung von Files.exists(input) kann das spätere Lesen nicht garantieren: Eine Datei kann nach der Prüfung verschwinden oder unzugänglich werden. Behandle den tatsächlichen Vorgang. Bevor du dich auf ein Verarbeitungsprogramm verlässt, teste fehlende Eingaben, fehlende Ausgabeordner, leere Dateien und Dateien nur mit Kopfzeile, CRLF-Zeilenenden, Text mit Akzentzeichen und fehlerhaft formatierte Datensätze. Benutzermeldungen sollten den betroffenen Pfad nennen; für die Fehlersuche bei einer umschließenden Ausnahme werden auch ihre ursprüngliche Ursache und ihr Stacktrace benötigt.