Softwareentwicklung in C++ - ASC

332 11. Exceptions
noch eine zusätzliche Kopie der Exception angelegt wird, da ja call-by-value
in C ++ der Standardmechanismus ist.
Um nicht missverstanden zu werden: Die Fallen, in die man beim Exception
Handling stolpern kann, sollen niemanden abschrecken, sondern nur
warnen, worauf man aufpassen muss. Exceptions sind etwas sehr Brauchbares
und sollen auch unbedingt verwendet werden! Die Behandlung von
irgendwelchen “Ausnahmezuständen” ist seit den Urzeiten der Softwareentwicklung
ein heißes Thema und Exceptions sind die sauberste und robusteste
Möglichkeit, mit unerwarteten Ereignissen umzugehen. Code, der robust und
fehlertolerant ist, ist eben bei weitem komplexer als Code, der nur so lange
funktioniert, wie alles im “Normalzustand” bleibt. Wer kann zum Beispiel
behaupten, dass im Falle von Netzwerken der andere Rechner immer erreichbar
ist oder überhaupt existiert? Wer kann vorherbestimmen, ob ein File,
das man öffnen will, garantiert vorhanden ist? Es ist also notwendig, eine
Fehlererkennung und entsprechende Behandlung in den Code einzubauen.
Es kursiert leider auch noch immer die große Angst vor Performanceproblemen
bei der Verwendung von Exceptions, da ein try ... catch ein
wenig ineffizienter ist, als z.B. eine Abfrage von return Werten. Diese Angst
ist allerdings im Normalfall unbegründet. Man darf nämlich nicht außer Acht
lassen, dass eine saubere und übersichtliche Programmstruktur in der Regel
eine effizientere Implementation von Algorithmen begünstigt.
Ein kurzer Vergleich des Exception Mechanismus mit alternativen Techniken
zur Fehlerbehandlung zeigt seine Stärken:
• Man kann einen Fehler ignorieren und einfach probieren, weiterzumachen.
Dass das katastrophale Folgen haben kann, versteht sich von selbst und
deswegen möchte ich diese Art der “Fehlerbehandlung” gar nicht näher
kommentieren.
• Man kann einfach bei einem Fehler das Programm beenden. Dieses Verhalten
führt früher oder später sicher zu einem größeren Desaster. Erstens ist
ein Programm, das sich bei jeder Gelegenheit beendet, eine Katastrophe
für die Benutzer. Zweitens bedeutet dieses Verhalten, dass intern durch das
willkürliche Unterbrechen von Abläufen schlimmste Inkonsistenzen entstehen
können. Sobald dann einmal aufgrund eines solchen Verhaltens eine
größere Datenbank inkonsistent ist, weil einfach beim Beenden nur die halben
Daten geschrieben werden konnten, kann man sich das Lachen kaum
noch verhalten. Dieses Verhalten ist also absolut unbrauchbar!
• Man kann im Fehlerfall eine Meldung z.B. auf Standard-Error schreiben.
Das Problem dabei ist, dass man ja trotzdem irgendwie mit dem Programm
fortfahren muss. Es muss also sowieso eine der anderen, hier erwähnten,
Strategien zusätzlich implementiert werden, denn sonst käme dieses Verhalten
dem Ignorieren des Fehlers gleich.
• Man kann aus allen Methoden und Funktionen im Fehlerfall bewusst
“unmögliche” Ergebnisse zum Signalisieren eines Fehlers liefern. Dies war