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