Wieso Speicheranforderung in Try...Finally ?

[Insider2004]

FreeAndNil macht nur bei globalen Instanzen Sinn.

function xyz;
var
A: ...
begin
...
A.Free;
end;

Hier z.b. wäre es Blödsinn. Da laufe ich sowieso aus dem Scope.

[DeddyH]

Richtig, aber andererseits würde es auch nicht wirklich stören. Was man auch häufiger sieht:

Delphi-Quellcode:

if Assigned(SomeObject) then
  SomeObject.Free;

Die Assigned-Abfrage ist genauso überflüssig, aber ich würde nicht hergehen und sie löschen, weil ich es einfach nicht ertragen kann oder die Stimmen in meinem Kopf es mir befehlen.

[Bbommel]

Hallo zusammen,

ich habe mir diesen ganzen und die verlinkten Threads mal sehr interessiert durchgelesen, weil ich auch schon seitdem ich hier mitlese (und manchmal schreibe) nicht nachvollziehen kann, wieso man so auf dieses try...finally pocht. Auch die Argumente, die bisher hier vorgebracht wurden, konnten mich nicht so richtig überzeugen - die Gegenargumente haben mir hingegen teilweise aus der Seele gesprochen.

Warum ich mich hier noch mal melde, obwohl schon ziemlich viel zu dem Thema geschrieben wurde, ist, dass mir ein Aspekt bisher viel zu kurz kam, auch wenn er durchaus schon erwähnt wurde - vielleicht bringt das ja noch mal neue Punkte auf, das try/finally-Gebot zu verstehen. Mir geht es um den Vergleich von try/except und try/finally.

Als Argument für try/finally wird immer wieder geschrieben, dass es das Programm robuster machen würde, weil so auch unerwartete Fehler behandelt würden. Meiner Einschätzung nach macht try/finally (zumindest so, wie es hier verwendet wird) aber genau diese Fehlerbehandlung eben nicht. Im finally-Block werden nur diejenigen Dinge aufgeräumt, die auch im Erfolgsfall aufgeräumt werden würden - das ist natürlich weniger schlecht, als würde man das auch noch lassen, aber eine Fehlerbehandlung ist das ja nicht. Will sagen: zwar hat man den Speicher wieder ordentlich freigegeben, die Funktion selbst und damit ggf. das Programm insgesamt sind aber in einem undefinierten Zustand. Bei den als Parade-Argument für die try-finally-Sache vorgebrachten ständig laufenden Hintergrund-Anwendungen ist das doch eigentlich viel kritischer.

Viel sauberer finde ich daher eigentlich statt des hier meist geschriebenen fast immer:

Delphi-Quellcode:

function myFunction (someParam: TsomeType): boolean;
...
begin
  a:=TA.Create;
  try
    Result:=a.DoSomething;
  except
    Result:=false;
  end;
  a.Free;
end;

(das soll nur das grobe Konzept verdeutlichen - warum jetzt "false" im Fehlerfall das richtige Ergebnis ist, soll hier mal egal sein)

Klar, wenn man den Fehler nach außen durchreichen will, muss man ihn halt erneut raisen und das ganze dann ggf. mit lustigen try/except/finally-Verschachtelungen versehen. Aber nur mit try-except hat man tatsächlich eine echte Fehlerbehandlung und auch hier wird übrigens im Fehlerfall aufgeräumt.

Meiner Meinung nach also:

• Wenn es tatsächlich um eine (kritische) Anwendung geht, die ggf. auch noch unattended vor sich hinwerkeln soll, bringen nur try/except- oder try/except/finally tatsächlich eine Fehlerbehandlung. Ein einfaches try/finally mag weniger schlimm sein als gar nix, aber das Programm läuft potentiell dennoch amok.
• In einer GUI-Anwendung sollte man meiner Meinung nach die bekannten kritischen Stellen mit try/except-Blöcken versehen, um auch dem Benutzer im Fehlerfall ein sauberes Feedback geben zu können (falls nötig) oder das Problem intern abzufangen und zu behandeln. Sollte bei einer nicht-kritischen GUI-Anwendung an einer eigentlich völlig harmlosen Stelle eine Exception auftreten (z.B. der mal erwähnte Hardware-Schaden), dann hat das Gesamtsystem aber ganz andere Probleme, bei denen ich nicht weiß, warum sich mein Programm darum kümmern sollte.

So.... bin mal auf eure Meinungen dazu gespannt.

Bis denn
Bommel

[DeddyH]

Zitat von Bbommel:

Als Argument für try/finally wird immer wieder geschrieben, dass es das Programm robuster machen würde, weil so auch unerwartete Fehler behandelt würden.

Quellen?

[Bbommel]

Zitat von DeddyH:

Zitat von Bbommel:

Als Argument für try/finally wird immer wieder geschrieben, dass es das Programm robuster machen würde, weil so auch unerwartete Fehler behandelt würden.

Quellen?

Na, dieser Thread. So hab ich hier die Hauptargumente für das try/finally jedenfalls verstanden: Auch im Fehlerfall werden die Ressourcen noch sauber freigegeben => das Programm wird robuster. Das Wort robuster schwirrte mir im Kopf rum, weil es HeZa in Beitrag #13 benutzt hat. Passt aber ganz gut zu dem, wie ich die Pro-Argumente bisher verstanden habe.

Bis denn
Bommel

[DeddyH]

Ich meinte Quellen für den 2. Teil: unerwartete Fehler werden nur bei try-finally behandelt (zumindest habe ich das so rausgelesen).

[Bbommel]

Ähm, nee, so war das nicht gemeint... Kann man das so lesen? Hmmm... ungeschickt formuliert vielleicht. Streiche das "so auch"...

[Luckie]

Dass try-finally Fehler behandelt ist falsch. try-finally ist ein Ressourcenschutzblock und auch im Fehlerfall belegte Ressourcen wieder frei zu geben. Eine Fehlerbehandlung findet im Except-Block statt.

[DeddyH]

Sagen wir das nicht die ganze Zeit?

[Luckie]

Wir ja, aber stahli in seinem letzten Posting nicht.

Und ein Ressourcenschutzblock macht eine Anwendung in sofern robuster, dass in einem Fehlerfall der Speicher nicht zu läuft. Nehmen wir an man bearbeitet in einer Schleife hunderte von Objekten (Bilder zum Beispiel). Jetzt kommt es bei mehreren Bildern zu Fehlern, warum auch immer. Habe ich jetzt keinen Ressourcenschutzblock, würde der allozierte Speicher nicht mehr freigegeben. Und das kann durch aus zu kritischen Situationen führen. Oder anderes Beispiel: Ich schreibe ein Programm welches Ressourcen benötigt, die nicht immer unbedingt verfügbar sind, weil der Server weggebrochen ist. Da haben wir wieder das gleiche Problem. Nicht immer muss ein Programm unbrauchbar sein, wenn mal eine Ressource nicht zur Verfügung steht.