8.1

Ein Zustand, der das Programm an der Fortführung des normalen Ablaufs hindert.

Division durch Null, eine zu bearbeitende Datei kann nicht gefunden werden, eine Methode erhält einen ungültigen Parameter.

Dass unerwünschte Ausnahmesituationen (die den normalen Programmablauf verhindern würden) kontrolliert abgefangen und behandelt werden, statt dass sie zum Ausfall des gesamten Programms führen.

Ein Wert, der eine Ausnahme kodiert, indem er außerhalb des fachlich gültigen Wertebereichs liegt (z. B. ein negativer Wert); das aufrufende Programm muss die Kodierung kennen, um darauf reagieren zu können.

Über bestimmte Rückgabewerte, die einer vorab festgelegten Definition möglicher Fehlersignale entsprechen (z. B. "-1" für "Division durch Null").

Technische Fehlersignale und fachliche Rückgabewerte müssen sich denselben Rückgabewert-Kanal teilen – diese Vermischung führt zu schlechter Softwarequalität.

Das aufrufende Programm.

1) Ein eigener Kanal für die Signalisierung von Fehlern (Entkopplung von fachlichen Rückgabewerten und Fehlersignalen), 2) eine eigene Datenstruktur für Fehlersignale, um differenziertere Fehlermeldungen zu ermöglichen, 3) das Erzwingen, dass aufrufende Programme mögliche Ausnahmen einer Methode abfangen müssen.

Weil dadurch sichergestellt werden kann, dass für häufige Fehlerquellen tatsächlich Lösungsstrategien im Programm existieren, statt dass Fehler unbemerkt ignoriert werden.

Der aufrufende Code kann anhand des Rückgabewerts nicht ohne Weiteres unterscheiden, ob es sich um ein gültiges fachliches Ergebnis oder um einen kodierten Fehler handelt (z. B. könnte "-1" theoretisch auch ein fachlich gültiger Wert sein). Das erhöht das Risiko von Fehlinterpretationen, macht den Code unübersichtlicher und erfordert, dass jeder Aufrufer die genaue Fehlercode-Definition kennt und korrekt auswertet – eine Fehlerquelle, die mit wachsender Anzahl an Fehlercodes immer unübersichtlicher wird (genau das Problem, das Herrn Koch widerfahren ist).

Weil ein einzelner Rückgabewert keine differenzierten Informationen über die Art des Fehlers transportieren kann und der Aufrufer die genaue Bedeutung jedes Signalwerts kennen und korrekt interpretieren müsste. Zudem gibt es keinen Mechanismus, der den Aufrufer zwingt, sich überhaupt mit möglichen Fehlern auseinanderzusetzen – ein Fehlersignal kann einfach ignoriert werden, ohne dass der Compiler das bemerkt.

Ein Komplettausfall würde alle Nutzer betreffen, nicht nur denjenigen mit der fehlerhaften Eingabe – das schadet der Außenwahrnehmung des Unternehmens und kann zu wirtschaftlichen Verlusten führen (z. B. durch entgangene Bestellungen). Ziel der Ausnahmebehandlung ist es daher, den Fehler kontrolliert und lokal zu behandeln (z. B. Eingabe ignorieren, dem Nutzer eine verständliche Nachricht anzeigen), statt dass er sich unkontrolliert auf das gesamte System ausbreitet.

Ein Kunde möchte nach seiner Bestellung Statistiken einsehen; dazu ruft das Online-Shop-System u. a. preisProArtikel() des Warenkorbs auf. Tritt dabei ein Fehler auf (z. B. ist der Warenkorb wegen eines Datenbankfehlers leer), müsste die Methode dies mit einem Fehlersignal statt eines gültigen Preises zurückmelden. Der Online-Shop (aufrufendes Programm) müsste dieses Signal erst interpretieren und in eine für den Kunden verständliche Fehlermeldung übersetzen. Problematisch: preisProArtikel() hat nur einen Rückgabewert, der so gleichzeitig für den fachlich korrekten Preis UND für ein technisches Fehlersignal genutzt werden müsste – eine Vermischung, die die Softwarequalität verschlechtert.

Eine Ausnahme ist ein Zustand, der ein Programm an der Fortführung des normalen Ablaufs hindert (z. B. Division durch Null, nicht gefundene Datei, ungültiger Parameter). In Programmiersprachen ohne eigenes Ausnahmebehandlungskonzept werden solche Situationen häufig über Fehlersignale kodiert – spezielle Rückgabewerte außerhalb des fachlich gültigen Wertebereichs (z. B. "-1"). Das Problem: Da eine Methode meist nur einen Rückgabewert besitzt, müssen sich technische Fehlersignale und fachliche Ergebniswerte diesen einen Kanal teilen, was zu Vermischung und schlechter Softwarequalität führt; zudem muss jedes aufrufende Programm die Fehlercode-Definitionen kennen und korrekt interpretieren, ohne dass dies erzwungen wird. Ein besseres Konzept sollte daher einen eigenen Kanal zur Fehlersignalisierung bieten (Entkopplung von fachlichen und technischen Werten), eine eigene Datenstruktur für differenzierte Fehlermeldungen bereitstellen und aufrufende Programme dazu zwingen, mögliche Ausnahmen abzufangen – genau das leistet das in Java integrierte Exception-Handling.