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

[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")

[Benedikt Magnus]

Zitat von SProske:

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

Dann hätten wir aber mit "try-except-finally" eine stillschweigend unter den Tisch gefallene unbehandelte Exception.

[SProske]

Zitat von Benedikt Magnus:

Zitat von SProske:

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

Dann hätten wir aber mit "try-except-finally" eine stillschweigend unter den Tisch gefallene unbehandelte Exception.

Ich würde jetzt sagen du hättest ein nicht korrekt freigegebenes TKlasse.
Die im except-Fall aufgetretene Exception sollte in beiden Fällen nach oben durchgereicht werden.

[Benedikt Magnus]

Zitat von SProske:

Ich würde jetzt sagen du hättest ein nicht korrekt freigegebenes TKlasse.
Die im except-Fall aufgetretene Exception sollte in beiden Fällen nach oben durchgereicht werden.

Gut zu wissen!
Dann gäbe es aber immer noch eine unbehandelte Exception. Dinge, die man im Fehlerfalle macht, sollten keine Exception werfen, oder diese zumindest selbst ordentlich abfangen und verarbeiten.

Ich habe nichts gegen ein solches Konstrukt, sehe aber auch nicht, wie es bei sicherer Programmierung notwendig wäre.

[Uwe Raabe]

Zitat von Benedikt Magnus:

Delphi-Quellcode:

Objekt := TKlasse.Create;

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

Objekt.Free;

Zitat von SProske:

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

Das Free wird auch dann nicht aufgerufen, wenn eine andere Exception als EIrgendwas auftritt.