Es geht primär um größere Anforderungen...
Wenn das der Fall ist, kann die Applikation sowieso nicht weiterlaufen. Und wenn nicht, tritt wieder mein bisher einziger Fall ein, bei dem ein Try-Finally Sinn macht, nämlich einen Security-Layer/Wrapper. Hier nach dem Motto: "Schaun mer mal, obs reicht. Wenn nicht, dann eben nicht". Hier würde der EOutOfMemoryException in eine andere
Exception gemappt werden bzw. würde das komplett transparent gehandhabt werden.
Nochmal: Ich weiss genau, wie Exceptions funktionieren und warum. Ich behaupte nur, das es nur diesen einen Fall für Try-Finally gibt und die Vorschläge (hier und in allen anderen Foren), GRUNDSÄTZLICH jedes "Free" in einen Finally-Block zu packen, Quatsch ist.
Genau wie mit dem Anschnallen im Auto. Auch wenn man sich anschnallt, sollte man möglichst Unfälle versuchen zu verhindern. Und auch wenn man zu 90% unfallfrei fährt, sollte man sich doch anschnallen.
Aber beim Unfall ist die Fahrt doch vorbei...
Verstehst Du? Tritt ein Fehler auf, gehts eh nicht weiterm AUSGENOMMEN mein Beispiel.
@DeddyH: Ich meine z.B. deinen Beitrag #2 in
http://www.delphipraxis.net/162202-s...ring-list.html
Diese Regel "sollten immer"... ist overkill. Die Regel muss lauten: "Wenn Du einen reentranten Zustand wieder herstellen kannst, dann tu es".
Wenn z.B. der Speicher begrenzt ist, und(!) es an der Stelle nicht weiter geht, kann ich mir Resourcenschutzblöcke echt sparen. Mit dem Beenden der Anwendung wird der Speicher eh freigegeben.
Nochmal:
Code:
MyStringList := TStringlist.Create;
Try
MyStringList.Add('A lot of strings');
Finally
MyStringList.Free;
End;
ist fast immer overkill.