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

BSI-Studie: Wie KI die Bedrohungslandschaft verändert

Der Bericht zeigt bereits nutzbare Angriffsanwendungen und bewertet die Risiken, die davon ausgehen.

4 Tagen ago

KI-Wandel: Welche Berufe sich am stärksten verändern

Deutsche sehen Finanzwesen und IT im Zentrum der KI-Transformation. Justiz und Militär hingegen werden deutlich…

4 Tagen ago

Wie ein Unternehmen, das Sie noch nicht kennen, eine Revolution in der Cloud-Speicherung anführt

Cubbit ist das weltweit erste Unternehmen, das Cloud-Objektspeicher anbietet. Es wurde 2016 gegründet und bedient…

4 Tagen ago

Dirty Stream: Microsoft entdeckt neuartige Angriffe auf Android-Apps

Unbefugte können Schadcode einschleusen und ausführen. Auslöser ist eine fehlerhafte Implementierung einer Android-Funktion.

4 Tagen ago

Apple meldet Umsatz- und Gewinnrückgang im zweiten Fiskalquartal

iPhones und iPads belasten das Ergebnis. Außerdem schwächelt Apple im gesamten asiatischen Raum inklusive China…

4 Tagen ago

MadMxShell: Hacker verbreiten neue Backdoor per Malvertising

Die Anzeigen richten sich an IT-Teams und Administratoren. Ziel ist der Zugriff auf IT-Systeme.

5 Tagen ago