Richtig. Stellen wir uns nun vor, wir haben eine Klasse mit so einer Methode drin (sagen wir ca. 20 LOC). Irgendwann denken wir uns, dass es evtl. ganz gut wäre, die
Exception durchzureichen. Gesagt, getan, ein "raise" ans Ende des Except-Blocks und fertig. Schon haben wir uns Platz für ein Speicherleck geschaffen und merken es nicht bzw. können uns nicht erklären, wo es herkommt. Zumindest ich würde nicht als Erstes daran denken, noch einen try-finally-Block drumherum zu schreiben, schließlich war das Leck vorher ja auch nicht da. Und nun erteile ich der anderen Partei das Wort, die finally aus Übersichtlichkeitsgründen weglässt.
Wenn ich in einem except-Block rumfummle, dann bin ich äußerst vorsichtig und so ein erneutes raise schreibt man ja sehr bewusst - da kann man dann durchaus auch dran denken, ggf. das finally drumrum zu bauen.
Letztlich ist es doch eine Frage der Gewohnheit, wie man programmiert. Wenn du eh immer ein try-finally drumrum hast, dann bist du es auch nicht groß gewohnt, diesen bei einem eingefügten raise zu ergänzen, denn er ist ja schon da. Bei mir wäre es halt genau andersrum...
Bis denn
Bommel
...der jetzt aber doch mal schnell guckt, ob er nicht irgendwo bei einem raise ein finally vergessen hat. Ahem.
