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.

[mkinzler]

Zitat:

Delphi-Quellcode:

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

ist meines Erachtens aber ein falsches Beispiel, den der Commit soll ja nicht auf jeden Fall getriggert werden.

Eher

Delphi-Quellcode:

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

[DeddyH]

Oder noch eher:

Delphi-Quellcode:

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

[Codehunter]

Also Idee gut, Beispiel Mist?

[DeddyH]

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

[mjustin]

Die nächste Steigerungsstufe wäre dann:

Delphi-Quellcode:

// ...

    try (Obj := TMyClass.Create)
      // mach etwas mit dem Objekt
      ...
    except
      // behandele die Exception
      ...
    end;

// ...

Und das Free kann man sich sparen, weil der Compiler Code erzeugt, mit dem der Destruktor nach dem "End" aufgerufen wird.

8-)

[Der schöne Günther]

Als ich noch hauptsächlich in Java unterwegs war und dann zu Delphi kam war ich auch erstmal baff wie so etwas wie try..except..finally fehlen kann.

Ganz ehrlich: Ich vermisse es nicht im geringsten. Andere Dinge fehlen mir sehr viel mehr. Wenn man es denn wirklich einmal braucht ist ein try..(try..except)..finally allein durch die Einrückung schon übersichtlicher, finde ich.

[Aviator]

Ich finde die Idee gut und vermisse das auch in Delphi seit ich vor Jahren das erste Mal in C# damit in Kontakt getreten bin.

Zitat:

Zitat von mjustin (Beitrag 1410310)

Die nächste Steigerungsstufe wäre dann:

Delphi-Quellcode:

// ...

    try (Obj := TMyClass.Create)
      // mach etwas mit dem Objekt
      ...
    except
      // behandele die Exception
      ...
    end;

// ...

Und das Free kann man sich sparen, weil der Compiler Code erzeugt, mit dem der Destruktor nach dem "End" aufgerufen wird.

8-)

Also eine Art using Direktive wie es sie in C# gibt? Das wäre natürlich auch was feines.

Code:

using (HttpClient client)
{
    DoSomethingWithClient(client);
}

[sh17]

Zitat:

Zitat von Codehunter (Beitrag 1410307)

Also Idee gut, Beispiel Mist?

jupp, das wollte ich damit ausdrücken

[Codehunter]

Zitat:

Zitat von DeddyH (Beitrag 1410306)

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:

Zitat von DeddyH (Beitrag 1410308)

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:

Zitat von Codehunter (Beitrag 1410318)

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:

Zitat von Codehunter (Beitrag 1410318)

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

Zitat:

Zitat von Codehunter (Beitrag 1410318)

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:

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;

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

Zitat von TurboMagic (Beitrag 1410385)

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 :lol:

[Ghostwalker]

Es gäbe für so ein Konstrukt sicherlich den ein oder anderen Anwendungsfall. Aber wie der ein oder andere schon geschrieben hat, is das eher die Kategorie "nice to have", aber nicht "must have" :)

[Codehunter]

Zitat:

Zitat von Ghostwalker (Beitrag 1410409)

Es gäbe für so ein Konstrukt sicherlich den ein oder anderen Anwendungsfall. Aber wie der ein oder andere schon geschrieben hat, is das eher die Kategorie "nice to have", aber nicht "must have" :)

Sind anonyme Prozeduren das nicht auch? ;-)

[Ghostwalker]

Nein, die fallen eher in die gleiche Kategorie wie "with". Dinge die die Lesbarkeit von Code einfach nur unübersichtlich machen (Über anonyme Funktionen lass ich mich jetzt lieber nicht aus :) ).

Dein Konstrukt würde aber, mindestens, die Übersichtlichkeit vom Code erhöhen :)

[Codehunter]

Ich würds ja gerne als Feature Request an Emba schicken, aber auf der Loginseite der Quality Central komme ich nicht weiter. Überall kann ich mich mit meinem EDN-Account einloggen nur auf dieser Seite nicht:

Zitat:

Sorry, an error occurred trying to log you in - please try again.

[Uwe Raabe]

Zitat:

Zitat von Ghostwalker (Beitrag 1410412)

Nein, die fallen eher in die gleiche Kategorie wie "with". Dinge die die Lesbarkeit von Code einfach nur unübersichtlich machen (Über anonyme Funktionen lass ich mich jetzt lieber nicht aus :) ).

Im Gegensatz zu with-Konstrukten kann man mit Anonymen Methoden aber Dinge tun, die anders nur wesentlich komplizierter (wenn überhaupt) realisierbar wären. Insofern erhöhen sie die Lesbarkeit dann doch irgendwie wieder. Die aktuelle Syntax ist zwar noch suboptimal, aber missen möchte ich sie deshalb auch nicht.

[Codehunter]

Also ich habe bei einigen Projekten viel mit JavaScript und jQuery zu tun. Die haben ja die anonymen Methoden zur Philosophie gemacht. Dort habe ich schon Codes mit 30 Verschachtelungsebenen gesehen. Da weiß man bei den ganzen asynchronen Abläufen irgendwann nicht mehr wann was wie abgearbeitet wird.

Sagen wir mal so: Anonyme Prozeduren sind nicht per se schlecht, fördern aber schlechten und unübersichtlichen Code. Quasi das Wasser zum Kochen von Spaghetticode.

[Uwe Raabe]

Zitat:

Zitat von Codehunter (Beitrag 1410423)

Anonyme Prozeduren sind nicht per se schlecht, fördern aber schlechten und unübersichtlichen Code. Quasi das Wasser zum Kochen von Spaghetticode.

Das ist aber jetzt das klassische Gegenbeispiel! Was du mit dem Wasser kochst, entscheidest ja nur du allein. Wenn du keinen Spagghetticode willst, dann koch in dem Wasser doch was anderes.

So wie mit jedem Tool kann man auch mit Anonymen Methoden schlechten bzw. schwer lesbaren Code schreiben. Wer sowas macht, braucht dazu aber vermutlich auch gar keine Anonymen Methoden, der kriegt das auch so hin. Dinge nur deswegen zu verteufeln, weil manche damit nicht richtig umgehen können, ist meiner Meinung nach auch nicht zielführend. Besser wäre es, den richtigen Umgang damit zu vermitteln - auch wenn das vielleicht nicht bei allen gelingt.

[Codehunter]

Sagen wir mal so: Ich habe schon sehr früh angefangen, Quellcodes nicht nur für mich zu schreiben sondern auch anderen zu zeigen. Daraus bekommt man viel Feedback zum Thema Lesbarkeit (deswegen ich es auch gut finde dass es jetzt die Delphi CE mit RTL- und VCL-Sourcen gibt).

Wenn ich aber Fremdcode sehe, der von Berlin nach Potsdam über München, Hamburg, Stuttgart, Dresden und Düsseldorf fährt, dann ist mir das ein Graus. Davon gibts für mich nur noch eine Steigerungsform, nämlich wenn mich Sprach- bzw. Syntaxeigenschaften selbst zu solchen Umwegen zwingen.