Konzept Fehlerbehandlung

IFS-Logo Diese Seite ist ein Teil der IsyFact-Standards. Alle Inhalte der Seite, insbesondere Texte und Grafiken, sind urheberrechtlich geschützt. Alle urheberrechtlichen Nutzungs- und Verwertungsrechte liegen beim Bundesverwaltungsamt.

Creative Commons Namensnennung Die Nutzung ist unter den Lizenzbedingungen der Creative Commons Namensnennung 4.0 International gestattet.

Java Bibliothek / IT-System

Name Art Version

isy-exception-core

Bibliothek

v3.2.x

1. Einleitung

Dieses Dokument enthält das technische Feinkonzept zur Fehlerbehandlung für alle Anwendungen gemäß Referenzarchitektur der IsyFact.

2. Aufbau und Zweck des Dokuments

Die prinzipiellen Anforderungen bei der Verarbeitung von Exceptions und das Fehlerbehandlungskonzept werden beschrieben. Es werden hierbei die Anforderungen von Betrieb, Nutzern und Softwarelieferanten berücksichtigt.

Ziel der im Kapitel Anforderungen an die Fehlerbehandlung beschriebenen Fehlerbehandlung ist:

  • das Erreichen eines effizienten und einheitlichen Umgangs mit Fehlern

  • die Gewährleistung der Wartbarkeit von Anwendungen durch aussagekräftige Fehler

  • die einfachere Wartung durch einen standardisierten Einsatz von Fehlerbehandlung und Fehlern

3. Anforderungen an die Fehlerbehandlung

Die generelle Anforderung an die Fehlerbehandlung ist das Erkennen, Signalisieren und Verarbeiten von Fehlern, die im System auftreten.

Konkret sollen damit Fehler möglichst effizient behandelbar sein, die Wartbarkeit bei Fehlern sichergestellt und Exceptions in einer standardisierten Form eingesetzt werden. Dies geschieht mit dem Ziel, die Implementierung zu vereinheitlichen und für den Anwender angemessene Informationen zur Verfügung zu stellen.

Aus den genannten Anforderungen ergeben sich entsprechende Detailvorgaben, die zur Umsetzung der generellen Anforderungen an die Fehlerbehandlung notwendig sind:

Nutzen stiftende Fehlermeldungen: Eine Fehlermeldung muss klar verständlich sein, vor allem, wenn sie dem Benutzer angezeigt wird. Außerdem müssen die Fehlertexte so aufgebaut sein, dass sie sowohl den Betrieb als auch die Entwickler bei der Ursachenforschung und der schnellen Bearbeitung unterstützen.

Zuordnung von Fehlern: Die IsyFact-Architektur beschreibt eine serviceorientierte Anwendungslandschaft. Das Ergebnis, das einem Nutzer angezeigt wird, entsteht durch das Zusammenspiel verschiedener Anwendungen, die jeweils Services anbieten. Ein gemeldeter Fehler muss in dieser Landschaft einer Anwendung zuzuordnen sein.

Eigene Fehlertexte für Drittanbieter-Komponenten: Für unchecked Exceptions von Drittanbieter-Komponenten, wie z. B. Hibernate, müssen eigene Fehlertexte für die Komponente (nicht für die einzelnen möglichen Exceptions) hinterlegt sein.

Exceptions sind Teil der Komponenten- / Anwendungsschnittstelle: Es muss dokumentiert sein, welche Exceptions eine Komponente bzw. Anwendung an den Aufrufer weiterreicht.

Einfache Nutzung der Fehlerbehandlung: Die Nutzung der Fehlerbehandlung muss einfach sein. Das Vorgehen, wie und wann Fehler gemeldet werden, soll möglichst einfach sein.

Übersichtlichkeit: Die Fehlerbehandlung soll übersichtlich bleiben, d. h. auch das Melden von Fehlern soll sinnvoll und überschaubar sein. Der Code zur Fehlerbehandlung soll nicht über die ganze Anwendung verstreut werden.

Wartbarkeit von Fehlern: Die Anzahl der möglichen Fehler in einem System steigt mit der Größe des Systems. Es muss also sichergestellt werden, dass ein Überblick über die möglichen Exceptions vorhanden ist und hier keine Redundanzen entstehen.

Einfache Pflege von Fehlertexten: Fehlertexte eines Systems müssen einfach pflegbar und standardisiert sein.

Unterscheidung nach Art: Die verwendeten Exceptions müssen in fachliche / technische und checked / unchecked Exceptions unterschieden werden können.

Konsistenter Systemzustand: Die Konsistenz des Systems, insbesondere der Daten, muss in (unerwarteten) Fehlersituationen gewährleistet sein. Außerdem darf dies nicht zu einem unkoordinierten Absturz des Systems führen.

3.1. Prinzipielles Vorgehen

Exceptions werden grundsätzlich nur zur Signalisierung abnormer Ergebnisse bzw. Situationen eingesetzt.

Bei Eintritt einer solchen Situation muss der Aufrufer die Exception behandeln, sofern er diese behandeln kann. Dies gilt allgemein für die gesamte Fehlerbehandlung.

Das Konzept der in den folgenden Kapiteln beschriebenen Fehlerbehandlung zeigt die Abbildung 1.

fehlerbehandlung003
Abbildung 1. Prinzip der Fehlerbehandlung

In einer Komponente gelten die Schnittstellenbeschreibungen, die durch die Signaturen der aufgerufenen Methoden festgelegt sind. Hier auftretende Fehler sind zu behandeln, sofern möglich (siehe 1). Ist dies nicht möglich, so reicht der Aufgerufene die Exception in der Aufruf-Hierarchie nach oben weiter, d.h. zur aufrufenden Komponente (siehe 2) oder direkt zur Schnittstelle, sofern die Komponente von dort aufgerufen wurde.

Komponenten bilden Anwendungen. Auch auf Anwendungsebene gilt analog, dass die hier auftretenden Exceptions innerhalb der Anwendung behandelt werden müssen (siehe 2). Ist es auf Anwendungsebene nicht möglich die Exception zu behandeln, so greift die oberste Schicht der Anwendung, die sog. Exception-Fassade. Diese ist Teil der Schnittstelle. Sie fängt alle Exceptions, die nicht durch die Anwendung selbst behandelt werden konnten. Die Exception-Fassade bereitet diese Exceptions für den Aufrufer gemäß der Schnittstellenbeschreibung auf und reicht sie an den Aufrufer weiter (siehe 3). Die hier weitergereichten Exceptions werden als Transport-Exceptions bezeichnet.

Anmerkung zur Verknüpfung von Fehlern in Anwendungs- und Datenbank-Logs

Wie in Abbildung 1 zu sehen, werden Fehler spätestens auf der Schnittstellenebene behandelt und geloggt. Bei aufgetretenen Datenbank-Fehlern liefert die Datenbank-Schicht die Datenbank-Fehlermeldung als Teil der Fehlermeldung zurück. Spätestens an dieser Stelle wird also der Fehler in das Anwendungs-Log geschrieben, inklusive eines Zeitstempels und des Stack Traces. Nähere Details zum Logging finden sich im Konzept Logging. Mithilfe des Zeitstempels, der Datenbank-Fehlermeldung und des Stack Traces kann dann die Verbindung zur Fehlermeldung im Datenbank-Log hergestellt werden.

Die Verknüpfung von Anwendungsfehlern über mehrere Anwendungen bzw. deren Log-Dateien hinweg geschieht über zwei IDs, die im Dokument Nutzungsvorgaben Fehlerbehandlung beschrieben sind.

Anmerkung zum Fehlen des Stack Traces bei mehrfachen Wiederholungen einer Exception

In Java kann es passieren, dass bei mehrfachen Aufkommen einer Exception diese keinen Stack Trace mehr enthält. Dies kommt daher, dass eine Methode rekompiliert werden kann, falls sie eine Exception häufiger wirft. Bei dieser Rekompilation kann es passieren, dass der Compiler eine schnellere Taktik mit präallozierten Exceptions wählt, die keinen Stack Trace zur Verfügung stellen. Dieses Verhalten kann mit dem JVM-Parameter -XX:-OmitStackTraceInFastThrow abgeschaltet werden. Dies soll jedoch vermieden werden.

3.2. Ausnahmen und Rückgabewerte

Für die Fehlerbehandlung ist es wichtig, den Unterschied zwischen Ausnahmen und Rückgabewerten zu verstehen und zu wissen, wann sie eingesetzt werden.

Rückgabewerte sind das Ergebnis von Methodenaufrufen. Über definierte Werte (Rückgabewerte, englisch: return codes) kann der Erfolg eines Aufrufs signalisiert werden. Validierungen, also die (fachliche) Prüfung von Eingabewerten erfolgt in der Regel über Rückgabewerte (Fehlerlisten o.Ä.).

Ausnahmen (englisch exception) sind ein Konzept moderner Programmiersprachen, um die Bearbeitung von Fehlersituationen in gewissen Grenzen zu erzwingen und vom Compiler überprüfen zu lassen. Sie dienen dazu, Fehler an den Aufrufer zur Behandlung weiterzureichen. Ausnahmen sind zum Signalisieren von abnormen Ergebnissen gedacht. Sie werden eingesetzt, wenn ein Fehler vorliegt.

Eine Java-Methode kann Ergebnisse auf zwei Wegen zurückgeben. Im einfachsten Fall wird ein Ergebnistyp zurückgegeben. Daneben kann eine Methode auch eine Ausnahme (Exception) auslösen. Ausnahmen sollten nur benutzt werden, um ein abnormales Verhalten zu signalisieren. Für die Fehlerbehandlung sind in der Regel Ausnahmen zu verwenden.

Bei der Betrachtung von Komponentengrenzen spielen Ausnahmen eine besondere Rolle. Komponenten werden durch ihre Schnittstellen beschrieben, wozu auch die verwendeten Exceptions gehören. Eine Komponente darf nur die in ihrer Schnittstelle aufgeführten Exceptions (oder Unterklassen hiervon) an den Aufrufer weiterreichen. Alle übrigen Exceptions müssen von der Komponente behandelt werden oder in eine Exception der Schnittstellendefinition transformiert werden.

Ausnahmen können als Nachricht an einen menschlichen Nutzer dienen, z. B. in einer Log-Datei, oder bereits von aufrufenden Komponenten sinnvoll behandelt werden. Daher ist es erforderlich, die Fehlersituation so genau wie möglich zu beschreiben. Dazu ist eine Klassifikation in fachliche und technische Fehler sinnvoll. Fachliche Fehler treten bei der korrekten Nutzung einer Komponenten-Schnittstelle auf. Technische Fehler werden von der unterliegenden Technik durch eine Ausnahme signalisiert.

Daher benötigt jede Komponente drei Exception-Hierarchien:

  • Komponenten-Ausnahmen (technisch/fachlich erwartet),

  • Komponenten-Ausnahmen (technisch unerwartet) und

  • Schnittstellen-Ausnahmen (technisch/fachlich erwartet).

Diese werden im Dokument Nutzungsvorgaben Fehlerbehandlung beschrieben.