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.

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

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.

[TurboMagic]

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

Tja, normalerweise funktioniert das. Was hast du als EDN account genommen? Den Benutzernamen oder die E-Mail Adresse? Ich nahm den benutzernamen und lkann fröhlich Feature Requests und Bugreports ins System eingeben...
Ggf. mal versuchen deine EDN Kontodetails zu finden, weil dort sicher irgendwo der Benutzername drin steht. Falls das alles nichts hilft EMBT support kontaktieren. Wenn nicht klar ist über welche E-Mail Adresse dann nochmal melden, ansonsten die Reportnummer hier melden. Dann können wir abstimmen und den Report beobachten.

Grüße

TurboMagic

[Uwe Raabe]

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

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.

[Delphi-Laie]

Zitat von Codehunter:

Was haltet ihr davon?

Sehr viel!

Ich muß gestehen, daß mir die Erklärungen der verschiedenen try....-Konstrukte unvollständig erschienen, ja, das behinderte sogar mein Verständnis derselben. Mir leuchtete z.B. nie ein, warum eine eventuell auftretende Ausnahme, deren Behandlung mit "except" eingeleitet wird, nicht manche Situationen nach sich zieht (ziehen kann), in denen sichergestellt werden muß, daß bestimmte Operationen auch bei Auftreten einer Exception vollständig abgeschlossen werden (mit "finally" eingeleitet").

Die Lösung ist so (")einfach("), nämlich die Kombination (Verschachtelung) beider. Das fand ich erstmals in einem Delphi-Buch und hier nun auch wieder. Das mag zwar recht flexibel sein, doch es wirkt aufgebläht, gestelzt, konstruiert bzw. "gebastelt".

Warum die Entwickler dieser komfortablen Hochsprache das nicht besser gelöst haben (lösen konnten?), ist mir rätselhaft. Vielleicht liegt es aber auch nur an meinem mangelhaften Verständnis, und es geht eben nicht besser.