Was würdet ihr von einem try-except-finally-Konstrukt halten?

[sh17]

Zitat von Codehunter:

Also Idee gut, Beispiel Mist?

jupp, das wollte ich damit ausdrücken

[Codehunter]

Zitat von DeddyH:

Oder noch eher:

Delphi-Quellcode:

o := TKlasse.Create;
try
  TuWas;
except
  on E: EIrgendwas do FehlerBearbeitung;
finally 
  o.Free;
end;

So hab ich das noch gar nicht gesehen. Du meinst, dass nach der Abarbeitung vom except-Abschnitt auch noch in den finally-Abschnitt hinein gelaufen wird?

Wäre eine Überlegung wert, aber dann nicht mehr 100% abwärtskompatibel. Denn stell dir mal vor, du würdest einen bestehenden try-except-Block, wo es schon ein .Free im exception-Abchnitt gibt, um einen finally-Abschnitt nach dem neuen Konzept ergänzen. Wenn du darin dann auch ein .Free machst, kracht es natürlich bei einer Exception, weil das Objekt versucht wird doppelt freizugeben.

Zitat von DeddyH:

Zu dieser Idee gibt es schon einige Threads, da müssten eigentlich sämtliche Pros und Contras erörtert worden sein.

Gut möglich, doch such hier mal nach "try" und versuch da was zu finden ^^

[DeddyH]

Du musst schon nach try except finally suchen

[mkinzler]

Bei einem Fehler im try wird die Ausführung abgebrochen und der Code im except-Block ausgeführt (falls vorhanden). finally wird immer ausgeführt.
Code der nur bei Fehlerfreiheit ausgeführt werden soll, kann man ja einfach in den try-Block packen.

[sh17]

Zitat von Codehunter:

Wäre eine Überlegung wert, aber dann nicht mehr 100% abwärtskompatibel. Denn stell dir mal vor, du würdest einen bestehenden try-except-Block, wo es schon ein .Free im exception-Abchnitt gibt, um einen finally-Abschnitt nach dem neuen Konzept ergänzen. Wenn du darin dann auch ein .Free machst, kracht es natürlich bei einer Exception, weil das Objekt versucht wird doppelt freizugeben.

Das Free sollte generell im finally stehen, hat eigentlich im except nichts verloren. Was machst Du denn wenn es keine exception gibt? Dann gibt es auch kein Free?

[Uwe Raabe]

Zitat von Codehunter:

Du meinst, dass nach der Abarbeitung vom except-Abschnitt auch noch in den finally-Abschnitt hinein gelaufen wird?

Zitat von Codehunter:

Denn stell dir mal vor, du würdest einen bestehenden try-except-Block, wo es schon ein .Free im exception-Abchnitt gibt, um einen finally-Abschnitt nach dem neuen Konzept ergänzen.

Das ist dann aber vorher schon falsch umgesetzt worden. Das Free muss ja in jedem Fall aufgerufen werden, also muss es ja auch schon außerhalb des except-Blocks irgendwo vorkommen. Das wäre dann aber nicht in einem außen oder innen liegenden try-finally sein, denn dann würde es ja dort auch schon krachen. Also muss der Code beim Erweitern des try-except auf ein try-except-finally sowieso umgebaut werden.

Wenn das try-except-finally dazu da ist, ein Konstrukt wie dieses zu ersetzen, ja. Und nur so ergibt es ja auch Sinn.

Delphi-Quellcode:

o := TKlasse.Create;
try
  try
    TuWas;
  except
    on E: EIrgendwas do FehlerBearbeitung;
  end;
finally 
  o.Free;
end;

Der Gewinn ist allerdings nicht gerade üppig. Man spart lediglich ein try, ein end und eine Einrückungsstufe. Ist also lediglich Kosmetik, aber Aussehen ist ja auch manchmal wichtig.

[freimatz]

Ich selber verwende fast nur noch interfaced Klassen. Der Bedarf nach finally ist dadurch drastisch gesunken. Habe daher kein Bedarf.

[freejay]

Also ich fände das gut! Dieses Geschachtel finde ich immer sehr unübersichtlich.

[Benedikt Magnus]

Was ist denn der Unterschied zwischen

Delphi-Quellcode:

Objekt := TKlasse.Create;

try
  Objekt.MacheEtwas;
except
  on E: EIrgendwas do Fehlerbearbeitung;
finally
  Objekt.Free;
end;

und

Delphi-Quellcode:

Objekt := TKlasse.Create;

try
  Objekt.MacheEtwas;
except
  on E: EIrgendwas do Fehlerbearbeitung;
end;

Objekt.Free;

?

[SProske]

Der Unterschied tritt dann auf, wenn in Fehlerbearbeitung eine neue Exception auftritt (entweder durch ein raise oder "aus Versehen")