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

[Codehunter]

Moin!

Wenn ich mir verschiedene Quellen so anschaue, insbesondere wenn man mit Datenbanken zu tun hat, fällt mir immer wieder auf wie sperrig das Exception-Handling eigentlich ist:

Delphi-Quellcode:

myBoolAllesOk := False;
try
  try
    myTransaction.StartTransaction;
    myDB.TuWas;
    myBoolAllesOk := True;
  except
    on E: EIrgendwas do myTransaction.Rollback;
  end;
finally
  if myBoolAllesOk then
    myTransaction.Commit;
end;

Und man muss sich drauf verlassen, dass die Transaction nicht auch noch zwischen dem Rollback und dem Commit zufällig anderswo eine Transaction gestartet hat. Um auf Nummer sicher zu gehen, gibts die mitlaufende boolsche Variable. Wie elegant wäre da sowas:

Delphi-Quellcode:

try
  myTransaction.StartTransaction;
  myDB.TuWas;
except
  on E: EIrgendwas do myTransaction.Rollback;
finally
  myTransaction.Commit;
end;

Soweit ich das überblicken kann ließe sich eine solche Spracherweiterung problemlos einbauen weil es rückwärtskompatibel wäre.

Was haltet ihr davon?

Grüße
Cody

[sh17]

Ja, so ein Konstrukt wäre sinnvoll,

aber warum nicht so?

Code:

  try
    myTransaction.StartTransaction;
    myDB.TuWas;
    myTransaction.Commit;
  except
    on E: EIrgendwas do myTransaction.Rollback;
  end;

[Codehunter]

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.

[Frickler]

Zitat von Codehunter:

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 von Frickler:

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]

with qry:=TUniQuery.Create(nil), frm:=TMyForm.Create(nil) do // oder frm = ... ...Satan weiche! Wie schon immer berichtet nimmst du mit with dir die Debugging Möglichkeiten...vom Scope-Fehler mal abgesehen.

[mjustin]

Zitat von 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.

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 von Frickler:

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;

[TurboMagic]

Bitte nicht am eigentlich eher als deprecatet gekennzeichneten with Konstrukt noch erweiterungen vornehmen lassen. Sonst geht dir noch Nick Hodges nach, wenn er erfährt, dass du der vorschlagende warst!

[Codehunter]

Zitat von TurboMagic:

Bitte nicht am eigentlich eher als deprecatet gekennzeichneten with Konstrukt noch erweiterungen vornehmen lassen. Sonst geht dir noch Nick Hodges nach, wenn er erfährt, dass du der vorschlagende warst!

Die Verbesserung war, dass ich es weggelassen habe