Exception Chaining in Java 1.4

Die Zeit vor Java 1.4

Bevor Java 1.4 veröffentlicht wurde, gab es drei Möglichkeiten, mit dieser Situation umzugehen. Erstens: Wie in Listing A dargestellt, konnte man die IOException bis ganz nach oben weiterleiten und die obersten Schichten im aufrufenden Stapel versuchen lassen, eine Ausnahme zu bearbeiten, über deren Typ sie nichts wussten. Zweitens: Wie bei der in Listing B dargestellten TaskException könnte man über die gesamte Kette immer allgemeinere Ersatz-Ausnahmen erstellen. Drittens: Man könnte eine eigene Exception-Unterklasse erstellen, die es ermöglicht, eine Throwable-Klausel mit der Ausnahme zu assoziieren. Diese letzte Möglichkeit wird in Henri Yandells Artikel „Two ways to work more effectively with Java exceptions“ sehr gut erklärt. Von diesem Optionen ist die dritte sicherlich die beste Wahl, allerdings lässt sie sich nicht mehr anwenden, wenn man durch die Verwendung von APIs anderer Anwender daran gehindert wird, seine eigene Exception-Unterklasse überall einzusetzen.

Mit Java 1.4

Glücklicherweise muss man mit Java 1.4 keine Kompromisse schließen.
Die Klasse java.lang.Throwable, die Basis der java.lang.Exception, verfügt nun über ein Datenfeld für Ursachen, das verwendet werden kann, um die wichtigen Details des Problems die ganze Kette hinaufzureichen, bis zum Anwender oder einer Log-Datei. Dieses Ursachenfeld kann entweder im Constructor von Throwable eingestellt werden oder mit Hilfe einer bestimmten Setter-Methode. Im ersten Fall fügt man nach dem String, der die Ausnahmemeldung in der Parameterliste des Constructors werden soll, einfach ein Throwable ein. Im zweiten Fall verwendet man die Methode initCause zur Einstellung der Ursache auf ein bereits erstelltes Throwable.

Es gibt auch eine entsprechende Getter-Methode, getCause, die allerdings nicht allzu häufig verwendet wird, da die Methode printStackTrace so verändert wurde, dass sie die gesamte Ausnahmekette nach unten untersuchen kann. Damit erhalten Entwickler die Möglichkeit, ihre Programmdesigns mit guten Kapselungen auszustatten, ohne dadurch ihre Fähigkeiten zur Fehlersuche und -behebung einzuschränken.

In Listing C ist zu erkennen, wie das Scheduler/Task-Setup angepasst wurde, um von der Ausnahmenverkettung in Java 1.4 profitieren zu können. Wenn die TaskException schließlich die Oberfläche erreicht hat, steht die IOException, welche die eigentliche Ursache war, noch immer zur Verfügung. Mit der Ausnahmenverkettung in der Werkzeugkiste von Java 1.4 gibt es für eine nachlässige Ausnahmenbehandlung keine Ausrede mehr.

Page: 1 2

ZDNet.de Redaktion

Recent Posts

Vorinstallierte Schadsoftware auf IoT-Geräten

Mit dem Internet verbundene Digitale Bilderrahmen oder Mediaplayer können mit Schadsoftware infiziert werden und sind…

6 Tagen ago

iOS und iPadOS 18.2 beseitigen 21 Sicherheitslücken

Schädliche Apps können unter Umständen einen Systemabsturz auslösen. Mindestens eine Anfälligkeit erlaubt eine Remotecodeausführung.

7 Tagen ago

Top-Malware im November: Infostealer Formbook bleibt Nummer 1

Sein Anteil an allen Infektionen steigt in Deutschland auf 18,5 Prozent. Das Botnet Androxgh0st integriert…

7 Tagen ago

Google schließt schwerwiegende Sicherheitslücken in Chrome

Betroffen sind Chrome 131 und früher für Windows, macOS und Linux. Angreifer können unter Umständen…

7 Tagen ago

Data Analytics: Dienstleister wachsen zweistellig

Marktforscher Lündendonk erwartet für das Jahr 2025 ein durchschnittliches Umsatzwachstum von 14,9 Prozent.

1 Woche ago

Open-Source-Malware auf Rekordniveau

Alarmierender Anstieg von Open-Source-Malware / Seit 2019 haben Sonatype-Analysen mehr als 778.500 bösartige Pakete aufgedeckt

1 Woche ago