Softwareentwicklung in C++ - ASC

11. Exceptions 323
Vorsicht Falle: Wie bereits demonstriert wurde, kann es durch Unachtsamkeiten
bei der Anordnung der catch Blöcke dazu kommen, dass manche davon
nicht erreichbar sind. Dieses Problem kann man leicht vermeiden, indem
man Klassen, die tiefer in der Ableitungshierarchie stehen, weiter oben fängt
und solche, die höher stehen, entsprechend weiter unten, um “den Rest” der
Exceptions, die nicht explizit mit ihrer genauen Klasse angegeben wurden,
auch noch sinnvoll zu fangen.
Das Verhalten von Exceptions, dass sie entsprechend ihrer Typenhierarchie
behandelbar sind, hilft enorm beim Design großer Libararies. Es hat
sich sinnvollerweise eingebürgert, dass es für eine Library einen bestimmten
Basis Exceptiontyp gibt, von dem alle anderen abgeleitet sind. Zum Beispiel
könnte man in einer Library mit mathematischen Klassen eine Basis
Exception MathException definieren. Davon abgeleitet wäre dann z.B. eine
DivisionByZeroException, eine VectorException, eine MatrixException,
etc. Sollte man bestimmte Exceptions gesondert behandeln wollen, fängt
man diese speziell, wenn nicht, reicht ein catch auf eine MathException und
dadurch fängt man automatisch alle möglicherweise auftretenden Exceptions
aus dieser Library.
Jetzt bleibt noch eine Frage offen: Was passiert, wenn eine Exception geworfen
wird, aber kein passendes catch dazu auffindbar ist? Irgendwann ist
ja das Stack Unwinding einmal am Ende des Stacks angelangt. In diesem
Fall wird eine Standard Behandlung durchgeführt, die üblicherweise zum
Programmabbruch mittels abort() führt. Wie dieser Mechanismus genau
funktioniert und wie man sich z.B. zu Debugging Zwecken noch in diesen
einklinken kann, wird in Abschnitt 15.7 besprochen. Im Augenblick genügt
es, zu wissen, wie man Exceptions sinnvoll fängt und ich möchte allen Lesern
unbedingt anraten, die Behandlung von Exceptions auch gewissenhaft
durchzuführen, damit es gar nicht erst zu sogenannten uncaught Exceptions
kommen kann.
Eine Anmerkung hätte ich noch zur Deklaration von möglichen Exceptions,
die aus einer Methode oder Funktion geworfen werden, mittels
throw(...): Ebenso wie beim Fangen von Exceptions, bei der nicht der
genaue Typ, sondern die Typenkompatibilität zählt, verhält es sich bei
der Angabe von Exceptions, die geworfen werden können. In der Angabe
mit throw(...) muss nur ein kompatibler Typ, also entweder die genaue
Exception oder eine ihrer Basisklassen angegeben sein. Man könnte
also zum Beispiel in unserem Demoprogramm in Zeile 78 auch einfach
throw(Exception) schreiben und würde damit kein Problem heraufbeschwören,
denn DerivedDException ist ja von Exception abgeleitet. Im
Falle, dass man ein Overriding einer Methode macht, bei der bereits ein throw
deklariert wurde, kann diese Deklaration in der abgeleiteten Klasse entweder
gleich sein, oder die Originaldeklaration einschränken. Das ist auch völlig logisch,
denn damit erreicht man, dass immer maximal die Exceptions geworfen