8.2

Die Klasse Exception.

Zur Behandlung vieler unterschiedlicher Ausnahmesituationen.

Division durch Null. Beispiel: int n = 0; return 1/n;

Zugriff auf ein Listenelement außerhalb des definierten Bereichs. Beispiel: int[] zahlen = new int[8]; zahlen[10] = 4;

Zugriff auf ein nicht instanziiertes Objekt. Beispiel: Kunde k = null; k.setName("Meier");

1) Die Exception wird innerhalb der Methode abgefangen. 2) Die Exception wird an das aufrufende Programm weitergeleitet. 3) Die Exception wird abgefangen und mit einer spezifischen Meldung an das aufrufende Programm weitergeleitet.

Das Sprachkonstrukt, mit dem Exceptions abgefangen werden; im try-Block stehen die kritischen Programmanweisungen, im catch-Block werden die Ausnahmen behandelt.Das Sprachkonstrukt, mit dem Exceptions abgefangen werden; im try-Block stehen die kritischen Programmanweisungen, im catch-Block werden die Ausnahmen behandelt.

Den fehleranfälligen Programmabschnitt.

Welche im try-Block auftretenden Ausnahmen abgefangen werden sollen und wie sie behandelt werden sollen.

Man profitiert noch nicht von allen Vorteilen der expliziten Ausnahmebehandlung, da das aufrufende Programm keine Möglichkeit erhält, selbst auf den Fehler zu reagieren.

Es zeigt in der Methodensignatur an, welche Exceptions von der Methode geworfen (weitergeleitet) werden können.

Um das Schlüsselwort throws, gefolgt von der Auflistung aller Exceptions, die in der Methode auftreten können.

Anhand der Methodensignatur (dem throws-Zusatz).

In das aufrufende Programm.

getMessage()

Es kann mit den folgenden Anweisungen normal fortfahren.

Nein, nicht alle

"Unchecked" Exceptions.

Sie sind alle Unterklassen von RuntimeException (das trifft z. B. auf alle Exceptions aus Tabelle 18 zu: ArithmeticException, ArrayIndexOutOfBoundsException, NullPointerException).

"Checked" Exceptions – sie müssen abgefangen werden. Dazu zählen auch selbst definierte Exceptions.

Sie nennt nur die technische Wirkung, nicht die eigentliche fachliche Ursache – für den Nutzer ist die Meldung dadurch unverständlich.

Es ermöglicht das Erzeugen (Werfen) einer Exception.

Die ursprüngliche Exception wird per try/catch-Block gefangen, um daraufhin mit throw eine neue Exception (z. B. erneut eine ArithmeticException) mit einer spezifischen, angepassten Fehlermeldung zu werfen.

Als Parameter an den Konstruktor der Exception.

Nichts – es muss weiterhin dieselbe deklarierte Exception abfangen; lediglich der Inhalt der Fehlermeldung hat sich verändert.

Ja

a) Im try-Block können viele unterschiedliche Exceptions auftreten, die jeweils separat behandelt werden sollen. b) Neben einer bestimmten Standard-Exception sollen zusätzlich auch alle anderen Exceptions abgefangen werden.

Es wird der Reihe nach überprüft, welcher catch-Block zur geworfenen Ausnahme passt; passt keiner der speziellen catch-Blöcke, wird sie im allgemeinen catch-Block (für Exception) abgefangen.

Weil alle Ausnahmen in Java Unterklassen von Exception sind.

Ein Block, in dem Anweisungen festgehalten werden, die unabhängig davon ausgeführt werden, ob im try/catch-Block eine Ausnahme aufgetreten ist und behandelt wurde oder nicht.

Nach den catch-Blöcken; er wird in jedem Fall ausgeführt, egal ob und welche Exception aufgetreten ist.

Für zwingend notwendige Aufräumarbeiten.

Ohne finally-Block gibt es zusätzlich zum normalen Ablauf drei weitere Möglichkeiten, wie der try-Block verlassen werden kann; für jeden dieser Fälle müsste man separat sicherstellen, dass die Aufräumarbeiten durchgeführt werden – der finally-Block bündelt das an einer einzigen Stelle.

Beim internen Abfangen trifft die Methode selbst eine Entscheidung (z. B. Rückgabe von 0), die für den konkreten Anwendungsfall unpassend oder zu unspezifisch sein kann. Bei der Weiterleitung erhält das aufrufende Programm – das oft mehr Kontext über die eigentliche Situation hat (z. B. der Online-Shop weiß, dass es um einen Kunden-Statistikaufruf geht) – die Verantwortung und Möglichkeit, angemessen auf den Fehler zu reagieren, statt sich mit einer pauschalen internen Lösung zufriedenzugeben.

Unchecked Exceptions (Unterklassen von RuntimeException) entstehen meist durch Programmierfehler (z. B. Division durch Null, Nullzugriff), die potenziell an sehr vielen Stellen im Code auftreten könnten – eine Zwangsbehandlung überall wäre unpraktikabel. Checked Exceptions signalisieren dagegen erwartbare, fachlich relevante Ausnahmesituationen (z. B. eine ungültige Eingabe), für die der Entwickler bewusst eine Behandlungsstrategie vorsehen soll – der Compiler erzwingt das, um sicherzustellen, dass solche Fälle nicht versehentlich übersehen werden.

Weil sich nur der Inhalt der Fehlermeldung ändert, nicht der Typ der Exception oder die Methodensignatur (throws ArithmeticException bleibt gleich). Das aufrufende Programm fängt weiterhin denselben Exception-Typ mit demselben try/catch-Aufbau ab – lediglich der Text, den getMessage() liefert, ist jetzt aussagekräftiger.

Da die Prüfung der Reihe nach erfolgt und alle Exceptions letztlich Unterklassen von Exception sind, würde ein an erster Stelle stehender allgemeiner catch-Block (für Exception) bereits jede Ausnahme abfangen – die spezifischeren catch-Blöcke danach würden nie erreicht. Die spezifischeren Blöcke müssen daher vor dem allgemeinen stehen, damit jede Exception zuerst mit dem passendsten, spezifischsten Block behandelt wird.

Ist der Warenkorb leer, kommt es beim Berechnen des Durchschnittspreises zur Division durch Null (ArithmeticException). Alternative 1: Die Methode fängt die Exception selbst per try/catch ab und gibt einfach 0 zurück – der Online-Shop erfährt nichts vom Problem. Alternative 2: Die Methode wird stattdessen mit throws ArithmeticException deklariert und leitet die Exception an den Online-Shop weiter; dieser fängt sie in einem eigenen try/catch-Block ab und gibt über getMessage() eine Meldung aus. Alternative 3: Damit die Meldung nicht nur "Division durch Null", sondern verständlich "Warenkorb ist leer" lautet, fängt preisProArtikel() die ursprüngliche Exception intern ab und wirft mit throw eine neue ArithmeticException mit dieser spezifischen Nachricht als Konstruktor-Parameter – der Online-Shop fängt weiterhin denselben Exception-Typ ab, erhält aber jetzt eine aussagekräftige Meldung.

Java bietet mit der Klasse Exception ein objektorientiertes Konzept zur Ausnahmebehandlung, ergänzt um vordefinierte Standard-Exceptions wie ArithmeticException, ArrayIndexOutOfBoundsException und NullPointerException. Beim Umgang mit einer Exception gibt es drei Alternativen: (1) Sie wird innerhalb der Methode mit einem try/catch-Block abgefangen und behandelt, ohne dass das aufrufende Programm informiert wird. (2) Sie wird mittels throws in der Methodensignatur an das aufrufende Programm weitergeleitet, das sie dann selbst per try/catch fängt und z. B. über getMessage() die Fehlermeldung ausliest. (3) Sie wird zunächst intern abgefangen und mit throw als neue Exception mit einer spezifischen, kontextbezogenen Fehlermeldung erneut geworfen. Zu einem try-Block können mehrere catch-Blöcke definiert werden, die der Reihe nach auf Passung geprüft werden; ein allgemeiner catch-Block für Exception fängt dabei alle nicht spezifisch behandelten Ausnahmen ab. Ein finally-Block wird unabhängig vom Auftreten einer Exception immer ausgeführt und eignet sich für zwingend notwendige Aufräumarbeiten. Nicht alle Exceptions müssen zwingend abgefangen werden: "Unchecked" Exceptions (Unterklassen von RuntimeException, z. B. alle Standard-Exceptions aus Tabelle 18) können, müssen aber nicht behandelt werden; alle anderen, sogenannte "checked" Exceptions – einschließlich selbst definierter Exceptions – müssen zwingend abgefangen werden.