Softwareentwicklung in C++ - ASC

318 11. Exceptions
Vorsicht Falle: Leider wird bei der Behandlung von Exceptions sehr oft
ein gravierender Fehler gemacht, der zum Teil auf Schlampigkeit, zum Teil
aber auch auf Unwissenheit beruht: Jede Exception, die innerhalb eines try
Blocks auftritt, bewirkt sofort das Anspringen des entsprechenden catch.
Das bedeutet, dass alle Statements, die unterhalb der Zeile stehen, in der die
Exception aufgetreten ist, nicht mehr ausgeführt werden. Sollte dort Code
stehen, der unbedingt immer ausgeführt werden muss (z.B. irgendein delete
von dynamisch allokiertem Speicher), dann hat man ein Problem, denn bis zu
dieser Zeile kommt man im Falle einer Exception ja nicht! Aus diesem Grund
muss man sich sehr gut überlegen, wie man try Blöcke setzt, damit man nicht
ins offene Messer läuft und einerseits zwar eine “schöne” Fehlerbehandlung
implementiert, die aber selbst gleich noch schlimmere Fehler macht und z.B.
wachsende Programme oder sonstige schlimme Inkonsistenzen verursacht!
Es stellt sich nun die Frage, wie wir die Exception, die in Zeile 135 geworfen
wurde, durch catch an einer ganz anderen Stelle im Programm fangen
können. Eigentlich müsste das Exception Objekt ja zu diesem Zeitpunkt
schon lange tot sein, da die throw Expression, in deren Rahmen das temporäre
Objekt generiert wurde, bereits fertig abgearbeitet ist.
Die Antwort darauf klärt auch gleich das Phänomen der zwei erzeugten
Objekte auf: Wird eine Exception geworfen, so wird immer (!) automatisch
eine Kopie dieser Exception generiert. Genau diese Kopie ist es, die wir
auch durch unser catch fangen und nicht, wie viele Entwickler annehmen,
das Original! Die Kopie ist ebenfalls ein temporäres Objekt und die Lifetime
dieses Objekts endet, sobald der catch Block verlassen wurde, denn dort ist
für den Compiler dann diese Expression zu Ende.
Jetzt, wo diese Eigenheit geklärt ist, können wir den Output zu Ende
analysieren:
1. In Zeile 167 wird ein Aufruf auf setElementAt mit Index 5 als Parameter
durchgeführt.
2. In Zeile 134, in der Implementation von setElementAt, wird eine Überprüfung
vorgenommen, ob dieser Index auch wirklich zulässig ist. Weil
wir aber die Instanz von Vector so angelegt haben, dass sie maximal 3
Elemente halten kann, wird entschieden, dass es mit der Zulässigkeit gar
nicht so weit her ist.
3. Es wird also entsprechend in Zeile 135 eine IndexOutOfBoundsException
als temporäres Objekt geworfen und dadurch wird die Methode an dieser
Stelle auch verlassen. Der Konstruktoraufruf des temporären Objekts
äußert sich im Output durch die Meldungen
default - constructing Exception, id = 0
default - constructing IndexOutOfBoundsException, id = 0
4. Wie bereits erwähnt, wird von throw sofort eine Kopie dieses Objekts
angelegt. Da wir einen Copy Constructor bereitgestellt haben, wird die-