AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Wieso Speicheranforderung in Try...Finally ?

Ein Thema von FredlFesl · begonnen am 12. Aug 2011 · letzter Beitrag vom 16. Aug 2011
Antwort Antwort
Seite 2 von 2     12   
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
10.052 Beiträge
 
Delphi 12 Athens
 
#1

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 11:50
Aber guter Code ist minimalistisch.
Vor allem aber robust. Was nützt es mir, wenn ein Programmcode 10 Zeilen weniger hat, dafür aber beim kleinsten Problem nicht mehr macht was er soll?

Was bei Speicherlecks passiert, konnte man in einigen Versionen vom Firefox sehr gut sehen. Oder auch in Delphi 2005. Und auch wenn euch beiden das anscheinend anders geht (ich weiß ja nicht, ob ihr 32 GiB RAM habt oder so...), aber 99% der Benutzer hat es durchaus gestört, wenn diese Programme im Laufe der Zeit viele hundert MiB RAM belegt haben. Bei ein paar Stunden Laufzeit waren es bei mir schonmal 2 GiB oder so, so dass wegen 32 Bit Schluss war und das Programm nicht mehr ging...

Ich möchte mit meinem PC produktiv arbeiten, dementsprechend kann ich mit Software, die Speicherlecks hat und meinen RAM vollmüllt, nicht so viel anfangen.

Aus dem gleichen Grund verwende ich "FreeAndNil" nicht. Ich will in meinem Code nicht gefragt werden: "Wieso machst Du das denn hier? Das ist überflüssig"
Gerade FreeAndNil ist an vielen Stellen sehr wichtig. Nämlich immer dann, wenn man später wissen will, ob das Objekt schon erzeugt wurde. Auch ein zweiter Aufruf an Free knallt sonst.

Ein Beispiel ist hier das Singleton-Pattern. Wie willst du denn wissen, ob das Objekt existiert, wenn du es nicht auf nil prüfen kannst?

Anderes Beispiel: Grundsätzlich eine Variable initialisieren: Stört nicht, wird eh wegoptimiert und ist robust. Und überflüssig und blöd.
Wenn eine lokale Variable nicht initialisiert wird, ist es russisches Roulette was dabei herauskommt.

Felder eines Objektes und globale Variablen werden automatisch initialisiert, so dass hier eine Initialisierung nur notwendig ist, wenn ein anderer Wert als 0, False, ... als Startwert benötigt wird. Besser lesbar sind definierte Anfangswerte aber definitiv, da man sonst immer erst schauen muss, ob vielleicht irgendwo anders noch etwas initialisiert wird.
Sebastian Jänicke
AppCentral

Geändert von jaenicke (13. Aug 2011 um 11:52 Uhr)
  Mit Zitat antworten Zitat
HeZa

Registriert seit: 4. Nov 2004
Ort: Dortmund
182 Beiträge
 
Delphi 10 Seattle Professional
 
#2

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 02:43
Nochmal:
Code:
MyStringList := TStringlist.Create;
Try
  MyStringList.Add('A lot of strings');
Finally
  MyStringList.Free;
End;
ist fast immer overkill.
Hm... diese Aussage ist ziemlich zweckfrei. Wenn du 6 Zeilen sinnlosen Code nimmst, bringt dich die Aussage, dass 3 davon überflüssig sind auch nicht weiter.

Aber du suchst ja nach einer Erklärung warum "immer" try-finally verwenden sollte.

1. Grund. Warum denn nicht?
Ein vergessenes try-finally kann ein Fehler sein, aber ein try-finally, dass nicht notwendig ist, ist niemals falsch. vielmehr macht es meinen Code robuster (z.B. für Erweiterungen oder für Verwendung an anderer Stelle). Meine Erfahrung: Da wo man das try-finally weglassen könnte, da stört es nicht und da wo es stört, kann man es nicht weglassen.

2. Grund: Lesbarkeit
Finde ich im Code eine Stelle an der eine Resource belegt oder ein Objekt erzeugt wird, will ich sofort als nächstes wissen wo die Freigabe ist. Ein try-finally ist da eine schöne Klammer die mich zu der Stelle mit der Freigabe führt.

3. Grund: Leichtes überprüfen auf Korrektheit
Um sagen zu können, dass Code in der Form
Code:
MyStringList := TStringlist.Create;
<Zeile1>
<zeile2>
<Zeile3>
MyStringList.Free;
kein Speicherleck produziert, muss ich für alle Zeilen dazwischen garantieren, dass diese keine Exceptionen werfen. Sobald da eine Prozedure aufgerufen wird, ist das keineswegs trivial.

Zeig doch mal eine Code-Stelle aus einem deiner Programmen wo dich so ein try-finally so richtig nervt.
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.666 Beiträge
 
Delphi 12 Athens
 
#3

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 12. Aug 2011, 18:20
Ich habe das Gefühl, dass Dir der Sinn des Exception-Handlings nicht ganz klar ist. Es ist ja nicht dazu da, um Fehler, die Du durch Schusseligkeit eingebaut hast, zu beheben, sondern um Ausnahmen (eben Exceptions) abzuhandeln. Es befreit einen nicht von der Pflicht, ggf. unumgängliche Ausgangszustände im Vorfeld abzuchecken. Tritt innerhalb eines try-finally-Blocks eine Exception auf, wird ja der finally-Teil in jedem Fall durchlaufen (sogar, wenn ein exit drinsteht), der except-Teil aber nur im Ausnahmefall. Verzichtet man auf Ressourcen-Schutzblöcke, dann hat man eben im Fehlerfall das Dilemma, dass der Code zum Freigeben nicht mehr ausgeführt wird.
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
Benutzerbild von Luckie
Luckie

Registriert seit: 29. Mai 2002
37.621 Beiträge
 
Delphi 2006 Professional
 
#4

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 12. Aug 2011, 18:33
Genau wie mit dem Anschnallen im Auto. Auch wenn man sich anschnallt, sollte man möglichst Unfälle versuchen zu verhindern. Und auch wenn man zu 90% unfallfrei fährt, sollte man sich doch anschnallen.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Medium

Registriert seit: 23. Jan 2008
3.689 Beiträge
 
Delphi 2007 Enterprise
 
#5

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 12. Aug 2011, 18:36
In der Fachlogik nutze ich z.B. nur try..finally, und im finally wird nach Resourcenschutz und ggf. Undos die Exception wieder geraised. In der GUI bzw. GUI-nahen Teilen dagegen wenn möglich nur try..except, um ggf. entsprechende Meldungen ausgeben zu können. Der Resourceschutz sollte möglichst komplett in der Fachlogik passiert sein, ebenso will ich keine eine ShowMessage() aus diesen jemals sehen, denn da gehören sie nicht hin.

Sinn des finally ist halt eben genau das, wie es heisst: Resourcen schützen, sprich Speicherleichen vermeiden.
"When one person suffers from a delusion, it is called insanity. When a million people suffer from a delusion, it is called religion." (Richard Dawkins)
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.358 Beiträge
 
Delphi 11 Alexandria
 
#6

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 12. Aug 2011, 19:02
@FredlFesl

In mir hast Du einen Verbündeten. Aber Du musst Dich entscheiden, ob Du Dich mit dem Rest der DP-Welt anlegen willst
-> http://www.delphipraxis.net/156651-b...erklaeren.html

Würde mich dann auch mal interessieren, ob Du mein Anliegen nachvollziehen kannst (zu dem ich immer noch stehe:
-> http://www.delphipraxis.net/160164-f...ewuenscht.html
Ich würde das für ein sehr nützliches Sprach-Feature halten.
Try-Finally-Blöcke haben auch ihren Nutzen, aber m.E. in anderen Anwendungsfällen.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.531 Beiträge
 
Delphi 12 Athens
 
#7

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 12. Aug 2011, 19:34
Und die "Anforderung" gehört NICHT in den Schutzblock, sondern direkt davor.
Ausnahme: Die entsprechende Variable wird vorher initialisiert und am Ende überprüft+freigegeben.

Geschützt (sicher freigegeben) werden die angeforderte Sachen, nach ihrer Anforderung und nicht die Anforderung selber,
denn geht diese schief, gibt's ja auch nix zum Freigeben.
Ein Therapeut entspricht 1024 Gigapeut.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   


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 09:24 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz