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

[Benedikt Magnus]

Zitat:

Zitat von SProske (Beitrag 1410330)

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:

Zitat von Benedikt Magnus (Beitrag 1410331)

Zitat:

Zitat von SProske (Beitrag 1410330)

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:

Zitat von SProske (Beitrag 1410332)

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:

Zitat von Benedikt Magnus (Beitrag 1410328)

Delphi-Quellcode:

Objekt := TKlasse.Create;

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

Objekt.Free;

Zitat:

Zitat von SProske (Beitrag 1410330)

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.

[SProske]

Zitat:

Zitat von Benedikt Magnus (Beitrag 1410333)

Zitat:

Zitat von SProske (Beitrag 1410332)

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.

Nur weil man try-except aufruft, heißt das ja nicht, dass man nicht eine Exception weiterreichen will, z.B.

- die abgefangene Exception auf eine eigene Exceptionsklasse ummappen
- eine Notfallroutine starten, aber die Exception trotzdem laufen lassen
- nur bestimmte Exceptions abfangen und alles andere weiterreichen

[Frickler]

Zitat:

Zitat von Codehunter (Beitrag 1410300)

Das war nur ein Pseudocode-Beispiel wie es in der Praxis oft vorkommt und sich viele was drunter vorstellen können. Anstatt der Transaction kann an sich auch irgend ein Object-Create-Free vorstellen.

Bei der Gelegenheit wäre eine Erweiterung von "with" auch praktisch:

Delphi-Quellcode:

with qry:=TUniQuery.Create(nil), frm:=TMyForm.Create(nil) do  // oder frm = ...
try
  qry.Connection := Datenmodul.MeineDB;
  qry.SQL.Text := 'SELECT bla FROM blubb WHERE fasel';
  [...]
  frm.Machwas;
  frm.ShowModal;
except
  on E: Exception do Blablubb;
finally
  frm.Free;
end;

Das wünsche ich mir schon lange :)

In diesem speziellen Fall (und ner kurzen Procedure) kann man natürlich auch "frm" einfach oben definieren. Aber wenn die Procedure länger wird, geht der Zusammenhang schnell verloren.

[Codehunter]

Gerade dann wenn zwischen dem try und dem except bzw. dem finally viel Quelltext steht, wenn sich innerhalb dessen noch ein paar try-Blöcke aufhalten, dann wird es schon recht unübersichtlich. Und auf das Problem als solches aufmerksam wurde ich, weil ich genau den Fall hatte wie im Eingangspost beschrieben: Eine Transaction sollte ein Rollback im Except-Fall machen und ein Commit im Finally-Fall. Allerdings musste ich das durch einen boolschen "Nebenläufer" absichern.

Zitat:

Zitat von Frickler (Beitrag 1410345)

Bei der Gelegenheit wäre eine Erweiterung von "with" auch praktisch

"with" ist sein einiger Zeit schon missbilligt wegen der Scope-Fehler. Ich habe früher sehr viel mit with gearbeitet und habe mir das komplett abgewöhnt. Der Code wird dadurch viel lesbarer. Auch wenns hier dann mehr Tipparbeit bedeutet. Aber das ist ein anderes Thema.

Das möchte ich auch noch mal betonen: Mir geht es vorrangig um die Lesbarkeit, was nicht gleichbedeutend ist mit möglichst kompaktem Code. Dass try-except-finally zu weniger Codezeilen führt ist eher ein unbeabsichtigter Nebeneffekt.

[haentschman]

Delphi-Quellcode:

with qry:=TUniQuery.Create(nil), frm:=TMyForm.Create(nil) do // oder frm = ...

...Satan weiche! :warn: Wie schon immer berichtet nimmst du mit with dir die Debugging Möglichkeiten...vom Scope-Fehler mal abgesehen. :roll:

[mjustin]

Zitat:

Zitat von Codehunter (Beitrag 1410350)

Gerade dann wenn zwischen dem try und dem except bzw. dem finally viel Quelltext steht, wenn sich innerhalb dessen noch ein paar try-Blöcke aufhalten, dann wird es schon recht unübersichtlich. Und auf das Problem als solches aufmerksam wurde ich, weil ich genau den Fall hatte wie im Eingangspost beschrieben: Eine Transaction sollte ein Rollback im Except-Fall machen und ein Commit im Finally-Fall. Allerdings musste ich das durch einen boolschen "Nebenläufer" absichern.

Exceptions sollten nicht zur normalen Ablaufsteuerung verwendet werden. Der finally Block ist für Code zum Freigeben von Objekten und anderen Systemresourcen vorgesehen.

Es geht ganz ohne "Nebenläufer":

Delphi-Quellcode:

BeginTransaction;
try
  MachWasMitDerDatenbank;
  CommitTransaction;
except 
  RollbackTransaction;
end;

[Codehunter]

Zumal mir an dem gegebenen Beispiel nicht so ganz klar wird, wofür das with hier überhaupt gebraucht wird, da beide Elemente (qry und frm) benannt sind und auch als benannte Elemente verwendet werden. Genau genommen hat man auf diese Weise eine Zeile gespart und zwei Keywords hinzugefügt. Aber wie gesagt, das ist ein Thema für sich.

Zitat:

Zitat von Frickler (Beitrag 1410345)

Delphi-Quellcode:

with qry:=TUniQuery.Create(nil), frm:=TMyForm.Create(nil) do  // oder frm = ...
try
  qry.Connection := Datenmodul.MeineDB;
  qry.SQL.Text := 'SELECT bla FROM blubb WHERE fasel';
  [...]
  frm.Machwas;
  frm.ShowModal;
except
  on E: Exception do Blablubb;
finally
  frm.Free;
end;

In abgewandelter Form siehts genauso aus und funktioniert sogar, bringt aber genauso wenig Nutzen:

Delphi-Quellcode:

qry:=TUniQuery.Create(nil); frm:=TMyForm.Create(nil); // oder frm = ...
try
   qry.Connection := Datenmodul.MeineDB;
   qry.SQL.Text := 'SELECT bla FROM blubb WHERE fasel';
   [...]
   frm.Machwas;
   frm.ShowModal;
except
   on E: Exception do Blablubb;
finally
   frm.Free;
end;