Softwareentwicklung in C++ - ASC

11. Exceptions 329
Der Grund hierfür ist leicht einzusehen, wenn man sich kurz überlegt, was
bei Exceptions passiert. Wir haben bereits diskutiert, dass bei einer Exception
das sogenannte Stack Unwinding stattfindet. Dabei werden natürlich
alle auto-Variablen aus dem Speicher entfernt (und natürlich destruiert), die
ihre Lifetime hinter sich haben, wenn der Block, in dem sie definiert wurden,
verlassen wird. Und jetzt stellen wir uns vor, dass eine Variable im Zuge des
Stack Unwindings destruiert wird und selbst eine Exception wirft. Welche
der beiden Exceptions soll jetzt behandelt werden? Die erste, die das Stack
Unwinding in Gang gesetzt hat oder die zweite, die während des Unwindings
passiert ist? Beide gleichzeitig behandeln geht nicht, eine davon einfach verwerfen
geht auch nicht, ein tolles Dilemma! Es wird in diesem Fall einfach der
brutale Weg gegangen und das Programm intern mittels abort abgewürgt.
Das wollen wir natürlich alle nicht, dementsprechend ist die starke Empfehlung
von oben unbedingt einzuhalten!
Vorsicht Falle: Wenn man unvorsichtig ist, kann es passieren, dass in einem
Destruktor eine Methode bzw. Funktion aufgerufen wird, die selbst eine Exception
werfen kann. In solchen Fällen darf niemals übersehen werden, dass
man im Destruktor selbst ein entsprechendes try-catch Konstrukt unterbringt,
ansonsten würde ja unabsichtlich die Exception aus dem Destruktor
hinaus geworfen werden!
Vorsicht Falle: Leider gibt es immer wieder Entwickler, die der Meinung
sind, dass man Exceptions am besten einfach ignoriert, um sie nach außen
zu verstecken. Zu diesem Zweck bauen sie sogenannte silent Catches in ihren
Code ein, also solche, die einfach einen leeren catch Block besitzen. Dies
darf man niemals machen, denn damit gelingt es bravourös, dass man Fehler,
die auftreten und sauber gemeldet würden, kommentarlos ignoriert. Damit
können sich dann Programme unheimlich komisch verhalten, weil sie eigentlich
intern in einem Fehlerzustand sind, aber trotzdem weiterlaufen, als wäre
nichts geschehen.
Die allerschlimmsten Exemplare von silent Catches, die man immer wieder
findet, sind solche, bei denen im leeren catch Block ein Kommentar à la
// this exception can never happen
steht. Der richtige Standpunkt dazu ist allerdings: Wenn die Exception nicht
auftreten kann, dann muss man zumindest einen Output einbauen, der den
“unmöglichen” Fall meldet. Hatte man Recht und die Exception tritt nie
auf, dann stört auch der Output nicht. Hatte man allerdings unrecht (sehr
oft, v.a. nach Programmänderungen!!!), dann sieht man wenigstens, dass ein
Fehler aufgetreten ist!
Vor allem sollte man sich wirklich überlegen, ob man ein solches catch
nicht gleich bleiben lässt und jemandem “weiter oben” die Behandlung
überlässt, für den Fall, dass die Exception doch auftritt.