Wieso Speicheranforderung in Try...Finally ?

[Uwe Raabe]

Zitat von DeddyH:

Und nun erteile ich der anderen Partei das Wort, die finally aus Übersichtlichkeitsgründen weglässt.

Wozu?

[DeddyH]

Aus Höflichkeit

[Bbommel]

Hi Luckie,

finde ich gut, dass wir uns zumindest einig sind, dass das try-finally keine Fehlerbehandlung ist. Manchmal entstand für mich beim Lesen der Threads der Eindruck, als würde das so gesehen, deswegen hatte ich es einfach mal so klar geschrieben.

Zitat von Luckie:

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.

Ja, aber! Das sind eigentlich doch schöne Beispiele, die unterstreichen können, was ich sagen wollte. In beiden Szenarien gibt es Situationen, in denen etwas schieflaufen kann (einmal eine komplexe Berechnung mit großen Datenmengen, einmal der Zugriff auf externe Ressourcen). Nun ist es natürlich nicht verkehrt, dann immerhin den Speicher wieder freizugeben, aber was ich meine ist ja: das hilft mir ja auch nur bedingt weiter, wenn dann halb bearbeitete Bilder im Speicher rumliegen oder Befehle an den Server nicht abgesetzt werden können. In beiden Fällen muss die Situation doch sauber bereinigt werden, also brauche ich (auch) ein Except.

Daher meine ich ja, dass ein try-finally das Ganze schon etwas "weniger schlimm" macht, aber wirklich stabil macht es das Programm nicht. Insofern finde ich halt, dass man nicht immer alles zwanghaft mit try-finally umklammern muss, aber andererseits dann da, wo etwas schiefgehen kann, die Exception auch wirklich mit try-except behandelt.

Damit möchte ich auch niemandem ein try-finally komplett ausreden. Ich sehe ja schon, dass ein Problem damit vielleicht weniger schlimm werden kann. Aber manchmal wirkt es halt so, als sei alles andere schlechter Stil, und das finde ich eben nicht.

[DeddyH]

Manchmal entstand aber andersherum der Eindruck, als sei es völlig unnötig, einen Ressourcenschutzblock zu verwenden. Wenn man sich aber daran gewöhnt, die Dinger immer zu benutzen, dann hat man sichergestellt, dass der reservierte Speicher auch garantiert wieder freigegeben wird (außer in extremen Härte-Situationen wie BSODs, aber dann ist ein Speicherleck wohl die kleinste Sorge), egal was zwischen try und finally steht oder aufgerufen wird. Das und nur das ist deren Sinn.

[Bbommel]

Zitat von DeddyH:

Richtig. Stellen wir uns nun vor, wir haben eine Klasse mit so einer Methode drin (sagen wir ca. 20 LOC). Irgendwann denken wir uns, dass es evtl. ganz gut wäre, die Exception durchzureichen. Gesagt, getan, ein "raise" ans Ende des Except-Blocks und fertig. Schon haben wir uns Platz für ein Speicherleck geschaffen und merken es nicht bzw. können uns nicht erklären, wo es herkommt. Zumindest ich würde nicht als Erstes daran denken, noch einen try-finally-Block drumherum zu schreiben, schließlich war das Leck vorher ja auch nicht da. Und nun erteile ich der anderen Partei das Wort, die finally aus Übersichtlichkeitsgründen weglässt.

Wenn ich in einem except-Block rumfummle, dann bin ich äußerst vorsichtig und so ein erneutes raise schreibt man ja sehr bewusst - da kann man dann durchaus auch dran denken, ggf. das finally drumrum zu bauen.

Letztlich ist es doch eine Frage der Gewohnheit, wie man programmiert. Wenn du eh immer ein try-finally drumrum hast, dann bist du es auch nicht groß gewohnt, diesen bei einem eingefügten raise zu ergänzen, denn er ist ja schon da. Bei mir wäre es halt genau andersrum...

Bis denn
Bommel

...der jetzt aber doch mal schnell guckt, ob er nicht irgendwo bei einem raise ein finally vergessen hat. Ahem.

[himitsu]

Man braucht nichtmal ein Re-Raise ... es braucht ja nur in dem ShowMessage (oder was auch immer dort steht) etwas passieren.

[jaenicke]

Zitat von Bbommel:

Wenn ich in einem except-Block rumfummle, dann bin ich äußerst vorsichtig und so ein erneutes raise schreibt man ja sehr bewusst - da kann man dann durchaus auch dran denken, ggf. das finally drumrum zu bauen.

Das kannst du bei privaten Projekten relativ leicht machen, aber wenn mehrere Personen an großen Projekten arbeiten, ist das ganze nicht mehr so einfach.

Insbesondere weil du auch gar nicht unbedingt weißt, wo in fremdem Code, auch z.B. in Drittanbieterbibliotheken, Exceptions auftreten können. Genauso weißt du aber nicht unbedingt, dass irgendwo so eine benutzt wird.
Deshalb ist es sinnvoller dies von vornherein abzusichern, dann braucht man sich nur um eine ordentliche Fehlerbehandlung weiter außen zu kümmern. Eben dort wo es Sinn macht. Dort wiederum kann man sich darauf verlassen, dass der Speicher der Unteraufrufe aufgeräumt ist und man "nur" einen definierten Programmzustand wiederherstellen muss.

Und wenn einer der anderen Entwickler irgendwo in einem Aufruf eine Bibliothek nutzt, die vorher nicht da war und die plötzlich eine Exception wirft, dann wird die zwar vom Exceptionhandler weiter oben abgefangen, aber da in dem restlichen Code die try..finally Blöcke nicht ergänzt wurden, der Speicher nicht freigegeben.

Das sind alles Unsicherheitsfaktoren, die man sich im professionellen Umfeld einfach nicht leisten kann. Code sollte so robust geschrieben sein, dass Änderungen an anderer Stelle nicht plötzlich Speicherlecks (oder Schlimmeres) aufreißen können (soweit eben möglich).

[FredlFesl]

Zitat von Uwe Raabe:

Zitat von DeddyH:

Und nun erteile ich der anderen Partei das Wort, die finally aus Übersichtlichkeitsgründen weglässt.

Wozu?

Weil ihr nicht lesen wollt: Ich lasse Finally (und auch das Try) dann weg, wenn ich Code an die Tafel schreibe.
Oder einen Codeschnippsel zur Erklärung irgendwo hin poste.
Oder wenn ich in einem Buttonclick irgend eine Funktion ausführe und dafür mal eben ein Objekt brauche.
Oder wenn ich an der Stelle eh nicht weitermachen kann.

Ich verwende Try-Finally genau dann (und nur dann), wenn ich einen Resourcen schützen möchte bzw. wenn ich die Exception abfangen muss.

Ich wiederhole mich: Ich kenne keine Speicherlecks in meinen Programmen. Es mag sie geben, aber FastMM zeigt sie mir nicht. Wozu dann also Try-Finally an den Stellen, an denen es überflüssig ist?

Mir scheint, die Diskussion ist am Ende, denn es gibt immer nur wieder Argumente, warum Try-Finally in bestimmten Situationen notwendig, korrekt, hilfreich oder essentiell ist. Nur ist das nicht das bzw. mein Thema. Ich programmierer weiss gott lange genug, um mir über die Feinheiten von Try-Finally im Klaren zu sein. Gerade deshalb will ich überflüssigen Schnickschnack vermeiden.

Zitat von jaenicke:

Es ist wie du so schön sagtest minimalistisch.

Nein, ist es nicht.
Object.Free ist minimalistisch bzw. FreeAndNil dann, wenn es unbedingt notwendig ist.

Zitat von jaenicke:

Warum sollte ich mir extra noch einen Status mitführen, ob ein Objekt noch existiert.

Wozu willst Du denn den Status mitschleppen, wenn Du es nicht benötigst? Ein privates Feld kann ich im Destruktor ruhigen Gewissens mit Free freigeben.

Zitat:

...Und es macht die Fehleranalyse auch einfacher, wenn ich weiß, dass eine Speicherschutzverletzung an einer höheren Adresse in keinem Fall von einem schon freigegebenen Objekt stammen kann.

Na ja, stimmt nicht ganz, nur erkennt man es vielleicht eher bzw. an der Adresse. Ich weiss aber nicht, wie Du programmierst, aber in meinen Anwendungen habe ich beim Entwanzen nicht mit Speicherschutzverletzungen zu kämpfen. Passiert schon mal, ist aber sehr schnell gefunden.

Aber gut. Der eine knallt seinen Code mit Try-Finally voll, der andere programmiert vielleicht so, das er es nur dann einsetzt, wenn es auch sinnvoll ist. Jedem das Seine.

-------
Ich setz mich jetzt übrigens in die Ecke und schmolle ganz fürchterlich, weil ihr mich nicht verstehen wollt.
Oder weil wir einfach aneinander vorbeireden.

[jaenicke]

Zitat von FredlFesl:

Ich wiederhole mich: Ich kenne keine Speicherlecks in meinen Programmen. Es mag sie geben, aber FastMM zeigt sie mir nicht. Wozu dann also Try-Finally an den Stellen, an denen es überflüssig ist?

Solange kein Problem auftritt, sind diese ja auch nicht sichtbar.

Zitat von FredlFesl:

Ich weiss aber nicht, wie Du programmierst, aber in meinen Anwendungen habe ich beim Entwanzen nicht mit Speicherschutzverletzungen zu kämpfen. Passiert schon mal, ist aber sehr schnell gefunden.

Die Aussage zeigt sehr deutlich, dass du eben nur kleinere Programme entwickelst. Und da kommt es halt auch nicht so darauf an.

Wenn aber ein Programm auf vielen hundert Rechnern im Einsatz ist, lassen sich eben unvorhersehbare Probleme nicht verhindern. Schon durch äußere Einflüsse, die durch Hardwareschnittstellen usw. kommen. Und in großen Programmen ist da nichts mit schnell gefunden, selbst mit Stacktraces und Logs sucht man nach der eigentlichen Ursache durchaus auch mal länger.

Kein Programm ist fehlerfrei, da kommt es eben auch mal zu Exceptions, wie man ja an diversen größeren Programmen sieht, egal ob Delphi, Eclipse, Lazarus, ... da kommen eben auch mal unbehandelte Exceptions. Nur deshalb kann man eben trotzdem in der Regel weiterarbeiten. Was wäre, wenn man jetzt nur deshalb immer wieder das Programm schließen müsste, weil bei den Fehlern der Speicher vollläuft?!?

Oder willst du behaupten, dass diese Exceptions alle leicht vorhersehbar gewesen wären und die Entwickler diese aus Spaß nicht behandelt haben?

Du stellst dir das glaube ich alles zu einfach vor bzw. auf kleinere Programme bezogen...

[Chemiker]

Hallo,

Zitat:

Ich verwende Try-Finally genau dann (und nur dann), wenn ich einen Resourcen schützen möchte

Das Problem dabei ist, dass man doch nicht immer voraus sehen kann ob diese Ressourcen geschützt werden müssen oder nicht. Wenn man die Ressourcen immer schützt, braucht man sich keine Gedanken darüber zu machen, ob das Programm in eine Situation kommt wo es gut gewesen wäre die angeforderten Ressourcen wären wieder freigeben worden.

Ein weiterer Punkt dabei ist, dass es meist erst im Echtbetrieb festgestellt wird, weil der Rechner auf dem das Programm läuft eine ganz andere Hardware hat, als der Entwicklungsrechner.

Bis bald Chemiker