Ein Konstruktor sollte doch niemals eine
Exception werfen. Und wenn, braucht man das Objekt nicht freizugeben, weil die Konstruktorlogik den Speicher selbst wieder freigibt, bevor sie die
Exception erneut schmeisst.
Try...Finally ergibt auch nur dann Sinn, wenn die
Exception in einem der Aufrufer abgefangen und behandelt wird. Wenn ich beispielsweise irgendeine Verbindung 'öffne' und dann etwas mit ihr anstelle, möchte ich, das die Verbindung garantiert wieder geschlossen wird, bevor eine Stufe höher die
Exception behandelt wird.
In C# gibt es übrigens etwas Ähnliches, nämlich das 'Using' - Konstrukt.
Im Grunde heißt Try-Finally nur, dass ein bestimmter Code versuchsweise ausgeführt werden soll, und anschließend garantiert ein bestimmter anderer Code
Stimmt nicht ganz (also, das 'versuchsweise'). Dann würde 'Exit' nicht in den 'Finally'-Block springen. das 'garantiert' ist das Wesentliche.
Es käme mir dabei eben nicht darauf an, wenn es "knallt".
...Ahh. Geht mit 'try...finally'
An unterschiedlichen Stellen kann Exit aufgerufen werden und final noch etwas erledigt werden.
...Ahh. Geht mit 'try...finally'
Wie Eingangs schon diskutiert, kann man mit jeder Menge if..begin...end..else.. und temporären Flags arbeiten, ggf. auch mit Goto (wenn es nicht gleich wieder Aufschreie gibt).
Uaaaaarghl! (zufrieden?
) Deshalb wurde doch gerade try..finally erfunden
Das sehr komfortable Exit(Value) lässt sich aber damit nicht nutzen.
Weswegen man eben mit try..finally arbeitet.
Dein 'FinallyExit' widerspricht dem Gedanken der blockorientierten Programmiersprache und schränkt den Programmierer unnötig ein.
Beispiel:
...
Delphi-Quellcode:
FuncA();
Try
FuncB();
Finally
CleanupFuncBCallAndDefinetlyNotTheFuncACall();
End;
Wie willst Du das mit deinem 'FinallyExit' modellieren? Beachte, das FuncA außerhalb des Try..Finally steht und dieser Aufruf nicht aufgeräumt werden soll, wenn er schiefgeht.