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 1 von 2  1 2      
FredlFesl

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 08:41
...Nicht wenn dein Leben das Programm ist, dann würdest du wahrscheinlich auch sehr darauf bedacht sein, dass du nach dem Unfall weiterlebst.
Da haben wir es!
Wenn "mein Leben" das Programm ist, dann benötige ich den Sicherheitsgurt, denn das Fahren ist nur eine Aktion, die kontrolliert schiefgehen können muss.

Ist "die Fahrt" mein Programm, dann muss ich mich nicht anschnallen. Peng => Programm-Neustart. Wieso muss ich einen Sicherheitsgurt tragen, wenn ich bei einem Unfall sowieso von Vorne anfange?


Zitat:
... 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.
Eben doch. Der code ist nicht sinnlos, sondern aus einem Beitrag, in dem die Verwendung der TStringlist erklärt wurde. In [b]diesem[b/] Schnippsel ist Try-Finally überflüssig.

Zitat:
Aber du suchst ja nach einer Erklärung warum "immer" try-finally verwenden sollte.
1. Grund. Warum denn nicht?
Stimmt, aber es ist überflüssig. Aber guter Code ist minimalistisch. 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"
Anderes Beispiel: Grundsätzlich eine Variable initialisieren: Stört nicht, wird eh wegoptimiert und ist robust. Und überflüssig und blöd.
Zitat:
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.
Wieso ist es wichtig, wo die Freigabe erfolgt? Ist doch komplett egal (außer, ich suche ein Speicherleck). Bei C# und Java suchst Du dich i.A. ja auch blöd, um die Freigabe eines Objektes zu finden.
Zitat:
Zeig doch mal eine Code-Stelle aus einem deiner Programmen wo dich so ein try-finally so richtig nervt.
Delphi-Quellcode:
  f := TFoo.Create;
  Try
    b := TBar.Create
    Try
      b.DoSomething();
      f.Work();
    Finally
      b.Free
    End
  Finally
    f.free;
  End;
// --- vs
  
  f := TFoo.Create;
  b := TBar.Create
  b.DoSomething();
  f.Work();
  b.Free
  f.free;
Das Bild hängt schief.
  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, 10:28
Prima, jetzt werden wir konkret
Delphi-Quellcode:
  f := TFoo.Create;
  Try
    b := TBar.Create
    Try
      b.DoSomething();
      f.Work();
    Finally
      b.Free
    End
  Finally
    f.free;
  End;
// --- vs
  
  f := TFoo.Create;
  b := TBar.Create
  b.DoSomething();
  f.Work();
  b.Free
  f.free;
also das würde ich schon mal umbauen zu:
Delphi-Quellcode:
  b := TBar.Create;
  try
    b.DoSomething();
  finally
    b.Free
  end

  f := TFoo.Create;
  try
    f.Work();
  finally
    f.free;
  end;
und wenn ich diesen Code sehe ...
Delphi-Quellcode:
  f := TFoo.Create;
  b := TBar.Create
  b.DoSomething();
  f.Work();
  b.Free;
  f.free;
sehe ich 2 potenzielle Speicherlöcher. Um sicher zu gehen, dass der Code keine Speicherlöcher erzeugt, muss ich nun prüfen, ob TBar.Create, b.DoSomething und f.Work keine Exceptions werfen. Falls ich Glück habe und TBar.Create erstellt, wie ich anhand der Namen vermute, tatsächlich ein neues Objekt, bin ich allerdings schnell damit fertig, weil dann eine EOutOfMemory-Exception geworfen werden könnte und damit wäre der Code für mich definitiv gefährlich.

Geändert von HeZa (13. Aug 2011 um 10:31 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 10:48
Wie sähe es denn so aus?

Delphi-Quellcode:
  f := TFoo.Create;
   b := TBar.Create
   b.DoSomething();
   f.Work(b);
   b.DoOther;
   b.Free
   f.free;
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 11:02
Lös doch einmal eine Exception in einem der Objekte aus. Kommst Du dann noch bis zum Free?
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 stahli
stahli

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 11:16
Nein, natürlich nicht.
- Das Programm ist fehlerhaft und muss korrigiert werden.
- Es ist unklar, was in f.Work und b.DoOther nun genau passiert ist und inwieweit Ergebnisse aus diesen Methoden noch brauchbar sind.

Diese beiden Punkte träfen aber auch zu, wenn die Aufrufe in try-Blöcke gekapselt wären.
Lediglich die zwei Pointer würden dann halt nicht mehr im Speicher rumdümpeln.

In sehr kritischen Zusammenhängen oder bei Referenzzählungen, externen Speicheranforderungen (@Uwe: ich hatte keinen roten Kasten vorhin) o.ä. würde ich ja auch Schutzblöcke einsetzen.
Aber nicht, wenn ich mir mal ein blödes Objekt erzeuge, und das kurz darauf wieder freigebe.

Code halte ich auch nicht für besser lesbar, wenn überall try-Blöcke verwendet werden.

Ich will ja niemanden missionieren, wollte nur ursprünglich mal nachfragen, wozu das Ganze und sagen, dass ich das halt so pauschal (immer noch) nicht nachvollziehen kann.


Aber ich habe Euch trotzdem alle ganz doll lieb - das muss auch mal wieder gesagt werden.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

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

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
FredlFesl

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 15. Aug 2011, 13:38
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.
Korrekt, aber dann ist mein Programm ja falsch. Ein fehlerfreies Programm benötigt kein FreeAndNil!
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?
Hmmm. Bei meinem Singleton-Pattern brauche ich das nicht und wenn, wäre es ein sinnvoller Einsatz. Ich sag ja nicht, das man es NIE benötigt, sondern nur NICHT IMMER. TRY-FINALLY braucht man auch, aber NICHT IMMER...

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.
Bitte lesen... "wird eh wegoptimiert" gilt ja wohl nicht für deinen Fall.

Ich rede von Grundsätzlich und Du kommst mit einzelnen Beispielen, wo es sinnvoll ist. Tut mir leid, das widerlegt meine Behauptung nicht ("Ausnahmen bestätigen die Regel"). Und: Ja natürlich gibt es Szenarien, wo ein FreeAndNil oder eine Variableninitialisierung wichtig ist. Ich bin ja nicht von Gestern.

Nur lese ich oft, das man immer FreeAndNil verwenden sollte, weil es ja nicht schadet. So ein Blödsinn.
Genauso blödsinnig wie: Variablen müssen immmer, d.h. ohne Nachdenken, initialisiert werden. Quatsch.
Oder eben: Create...Free (sorry: FreeAndNil) gehört immer zusammen mit einem Try-Finally.

Mich stört das "immer", weil es gleichbedeutend ist mit "ohne Nachdenken".

Klar: Ist immer noch besser als die Aussage: "Vergiss Try-Finally, das ist nur was für Angsthasen".

Also: In meinen Anwendungen steht dort, wo es nötig ist (und nur dort) Try-Finally.
FreeAndNil verwende ich nicht, denn meine Objekte werden nicht doppelt freigegeben. Letzteres habe ich mir so angewöhnt, es mag eine Marotte sein, aber seit dem laufen die Programme einfach besser: Vor allen Dingen sagt mir FastMM4, ob ich nicht aufgepasst habe.
Variablen werden nur dort initialisiert, wo es sinnvoll ist. Ich prüfe meine Anwendungen bis zum Release immer mit FastMM4, d.h. die ersten paar Monate laufen sie mit allen Prüfungen von FastMM. Erst wenn nix mehr passiert, deaktiviere ich die Reporting-Features.

[/QUOTE]Besser lesbar sind definierte Anfangswerte aber definitiv[/QUOTE] Das lasse ich gelten.
Das Bild hängt schief.
  Mit Zitat antworten Zitat
Benutzerbild von Neutral General
Neutral General

Registriert seit: 16. Jan 2004
Ort: Bendorf
5.219 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#8

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 15. Aug 2011, 14:07
Hallo,

Ich verwende auch nicht immer FreeAndNil. Auch nur wenn ich an anderer Stelle wissen muss ob das Objekt noch existiert - Und das hat nicht zwangsweise etwas mit schlechter Programmierung zu tun. Es ist manchmal einfach notwendig. Bei lokalen Objekten verwende ich FreeAndNil deswegen eben nicht. Bringt ja nix in den Stack ne 0 reinzuschreiben, die 10ms später wieder durch was anderes überschrieben wird

try-finally verwende ich allerdings immer. Ich hab es mir so angewöhnt und man ist einfach auf der sicheren Seite. Abgesehen davon finde ich sogar, dass try-finally Code auch um einiges schöner/strukturierter aussieht.
Bin der Meinung dass die Vorteile von try-finally einfach überwiegen. Das Programm wird vllt. 3 Byte größer und 1ms langsamer aber das ist es mir dann (allein schon aus oben genannten optischen Gründen) einfach wert.

Allerdings muss ich sagen, dass ich (meistens) auch kein Hardcore-Try-Finally Mensch bin. Also ich bin auch ab und zu mal etwas "großzügiger" und schreib sowas:
Delphi-Quellcode:
A := TA.Create;
B := TB.Create;
try
  DoSomething();
finally
  B.Free;
  A.Free;
end;
Denn zuuu verschachtelt ist mir dann doch meistens zu unleserlich. Aber so Fälle gibt es eigentlich eher selten. Meistens sind die try-finallys ja hintereinander
Michael
"Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination,
but because their imagination reveals worlds that others cannot see."
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 15. Aug 2011, 14:30
Auch ein zweiter Aufruf an Free knallt sonst.
Korrekt, aber dann ist mein Programm ja falsch. Ein fehlerfreies Programm benötigt kein FreeAndNil!
Nein, das ist nicht falsch. Es ist wie du so schön sagtest minimalistisch. Warum sollte ich mir extra noch einen Status mitführen, ob ein Objekt noch existiert. Wenn ich FreeAndNil benutzt habe, kann ich das einfach am Ende noch einmal hinschreiben. Ist es schon freigegeben, umso besser, wenn nicht, passiert es dort.

Wenn man 100%ige Kontrolle über den Programmfluss hat, braucht man das natürlich nicht, aber das ist eben nicht immer der Fall.

Ich benutze FreeAndNil bei Feldern eines Objekts immer. Einfach weil es die Fehlersuche erheblich vereinfacht, wenn ich weiß, dass in Speicherdumps oder ähnlichem alle schon freigegebenen Objektzeiger auch wirklich nil sind. 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.
Sebastian Jänicke
AppCentral
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

Registriert seit: 20. Jan 2006
Ort: Lübbecke
11.757 Beiträge
 
Delphi 12 Athens
 
#10

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 15. Aug 2011, 15:22
Ein fehlerfreies Programm benötigt kein FreeAndNil!
Blödsinn! Das hat nichts mit Fehlern zu tun, sondern lediglich mit Programmdesign - und das ist ja bekanntlich Geschmackssache.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2      


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 23:30 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