"FinalllyExit" gewünscht

[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.

[Sunlight7]

Zitat von jfheins:

Falls du das nicht glaubst, zeige bitte ein Stück Code wo das finally nicht ausgeführt wird

Code:

try
   Halt;
finally
   Beep;
end;

[himitsu]

Halt ist eine Ausnahme, denn dieses "schießt" das Programm direkt ab, genau da wo es ist,
das ist praktisch das selbe Ergebnis, als wenn man die Anwendung im Taskmanager abschießt.

Darum sollte man auch möglichst darauf verzichten.

[Stevie]

Ihr verlagert das Problem nur noch.... wenn im Konstruktor oder Destruktor eine Exception auftritt... Welche Art Exception? Programmierfehler? Sollte dann das Programm dafür sorgen, dass der ausgebügelt wird oder still und heimlich trotzdem weiterlaufen? Oder sollte man, wenn es zu erwarten ist, dass ein Fehler auftreten kann (z.b. man versucht eine Datei zu öffnen), nicht innerhalb der Methode mit try except arbeiten und somit letztlich sichergehen, dass der Aufruf des Konstruktors fehlerfrei abläuft? Ehrlich, wenn ich bei jedem Create und Free dafür sorgen müsste, dass ich mögliche Exceptions abhandle, hätt ich mich schon erhängt. Übrigens gibt's auch sowas, wie Unittests...