"FinalllyExit" gewünscht

[FredlFesl]

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.

Zitat von NamenLozer:

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.

Zitat von stahli:

Es käme mir dabei eben nicht darauf an, wenn es "knallt".

...Ahh. Geht mit 'try...finally'

Zitat von stahli:

An unterschiedlichen Stellen kann Exit aufgerufen werden und final noch etwas erledigt werden.

...Ahh. Geht mit 'try...finally'

Zitat von stahli:

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

Zitat von stahli:

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.

[himitsu]

Zitat:

versuchsweise ausführen

Logiksteuerung via Exceptions ist in der Regel eh verpöhnt.

Try-Finally/Except ist für den "Notfall" ... Exception = Ausnahme

Zitat von FredlFesl:

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.

Das stimmt schon, aber

Delphi-Quellcode:

A := TA.Create;
B := TB.Create;
try

Knallt es hier im B, dann gibt sich B selber wieder frei .... nur um das A kümmert sich keiner mehr.

PS: Ja, beim Erstellen und wärend der Bearbeitung sind A und B hier abgesichert, aber

Delphi-Quellcode:

finally
  A.Free;
  B.Free;
end;

Knallt es jetzt im A.Free, dann wird B nicht freigegeben.
Der einzige Grund, warum diese Vereinfachung "oft" Funktional ist, liegt darin begründet, daß das Free oftmals "weniger" Probleme bereitet.
Ist das nicht sichergestellt, dann kommt man um verschachtelte Try-Finally nicht drumrum.
Es sei denn man weiß, daß z.B. A.Free (nahezu) niemals Exceptions werfen kann, dann ist auch B.Free mit großer Sicherheit noch geschützt.

Ich selber nutze eine derartige Kombination vorallem dann, wenn ich eben weiß, daß A.Free problemlos abläuft und für den Fall, daß es da doch mal knallt, dann ist der Programmablauf eh dermaßen gestört, daß das Programm beendet werden muß und sich keine weitere Absicherung mehr lohnt.

Und ja, an Stellen wo sich keine Fehlerbehandlung "lohnt", weil dann eh nix mehr geht, dann erspare ich mir auch schonmal eine Exceptionbehandlung, wie Try-Finally und selbst Speicherfreigaben werden schonmal einfach weggelassen. (weil dadurch der Programmcode schonmal übersichtlicher/kürzer werden kann, ohne das es probleme gibt, da ich weiß das sich Windows am Programmende auch um vieles nochmal kümmert ... das war vor der NT-Reihe noch wesentlich aufwändiger/wichtiger)

[stahli]

Zitat von himitsu:

Der einzige Grund, warum diese Vereinfachung "oft" Funktional ist, liegt darin begründet, daß das Free oftmals "weniger" Probleme bereitet.
Ist das nicht sichergestellt, dann kommt man um verschachtelte Try-Finally nicht drumrum.
Es sei denn man weiß, daß z.B. A.Free (nahezu) niemals Exceptions werfen kann, dann ist auch B.Free mit großer Sicherheit noch geschützt.

Ich selber nutze eine derartige Kombination vorallem dann, wenn ich eben weiß, daß A.Free problemlos abläuft und für den Fall, daß es da doch mal knallt, dann ist der Programmablauf eh dermaßen gestört, daß das Programm beendet werden muß und sich keine weitere Absicherung mehr lohnt.

Und ja, an Stellen wo sich keine Fehlerbehandlung "lohnt", weil dann eh nix mehr geht, dann erspare ich mir auch schonmal eine Exceptionbehandlung, wie Try-Finally und selbst Speicherfreigaben werden schonmal einfach weggelassen. (weil dadurch der Programmcode schonmal übersichtlicher/kürzer werden kann, ohne das es probleme gibt, da ich weiß das sich Windows am Programmende auch um vieles nochmal kümmert ... das war vor der NT-Reihe noch wesentlich aufwändiger/wichtiger)

Genau so sehe ich das auch - aber eben auch für eine gesamte Methode. Wenn ich diese ausgiebig getestet habe und sicher bin, dass alles korrekt funktioniert (außer, wenn vielleicht der Hauptspeicher defekt ist o.ä.) dann kann ich auf solche Absicherungen auch verzichten, die eben aus meiner Sicht auch nur einen begrenzten Nutzen haben. Das Programm funktioniert ohnehin nicht mehr korrekt und der Fehler muss gefunden und beseitigt werden.

[FredlFesl]

[QUOTE=himitsu;1101916]

Zitat:

PS: Ja, beim Erstellen und wärend der Bearbeitung sind A und B hier abgesichert, aber

Delphi-Quellcode:

finally
  A.Free;
  B.Free;
end;

Knallt es jetzt im A.Free, dann wird B nicht freigegeben.

Jo, sowas ist ja auch extrem unsauber, gelle?

Zitat:

Es sei denn man weiß, daß z.B. A.Free (nahezu) niemals Exceptions werfen kann, dann ist auch B.Free mit großer Sicherheit noch geschützt.

Wenn es im Destruktor knallt, ist's doch eh zu spät. Dann benötigt die Schädelvorderseite eine intensive Holzbrettbehandlung.