AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Wieso Speicheranforderung in Try...Finally ?

Ein Thema von FredlFesl · begonnen am 12. Aug 2011 · letzter Beitrag vom 16. Aug 2011
Antwort Antwort
Seite 5 von 5   « Erste     345
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
9.844 Beiträge
 
Delphi 11 Alexandria
 
#41

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 13:46
Und nun erteile ich der anderen Partei das Wort, die finally aus Übersichtlichkeitsgründen weglässt.
Wozu?
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.459 Beiträge
 
Delphi 11 Alexandria
 
#42

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 13:53
Aus Höflichkeit
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Bbommel

Registriert seit: 27. Jun 2007
Ort: Köln
602 Beiträge
 
Delphi 11 Alexandria
 
#43

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 13:58
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.

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.
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.459 Beiträge
 
Delphi 11 Alexandria
 
#44

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 14:05
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.
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Bbommel

Registriert seit: 27. Jun 2007
Ort: Köln
602 Beiträge
 
Delphi 11 Alexandria
 
#45

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 14:10
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.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
40.503 Beiträge
 
Delphi 11 Alexandria
 
#46

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 14:30
Man braucht nichtmal ein Re-Raise ... es braucht ja nur in dem ShowMessage (oder was auch immer dort steht) etwas passieren.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
8.500 Beiträge
 
Delphi 10.4 Sydney
 
#47

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 18:00
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).
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
FredlFesl

Registriert seit: 19. Apr 2011
293 Beiträge
 
Delphi 2009 Enterprise
 
#48

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 20:28
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.

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.
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.
Das Bild hängt schief.

Geändert von FredlFesl (16. Aug 2011 um 20:33 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
8.500 Beiträge
 
Delphi 10.4 Sydney
 
#49

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 21:00
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.

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...
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Benutzerbild von Chemiker
Chemiker

Registriert seit: 14. Aug 2005
1.855 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#50

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 21:34
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
wer gesund ist hat 1000 wünsche wer krank ist nur einen.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 08:50 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf