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
FredlFesl

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

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
 
#2

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.073 Beiträge
 
Delphi 12 Athens
 
#3

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.783 Beiträge
 
Delphi 12 Athens
 
#4

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
Insider2004
(Gast)

n/a Beiträge
 
#5

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 15. Aug 2011, 15:33
FreeAndNil macht nur bei globalen Instanzen Sinn.

function xyz;
var
A: ...
begin
...
A.Free;
end;

Hier z.b. wäre es Blödsinn. Da laufe ich sowieso aus dem Scope.
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 15. Aug 2011, 15:37
Richtig, aber andererseits würde es auch nicht wirklich stören. Was man auch häufiger sieht:
Delphi-Quellcode:
if Assigned(SomeObject) then
  SomeObject.Free;
Die Assigned-Abfrage ist genauso überflüssig, aber ich würde nicht hergehen und sie löschen, weil ich es einfach nicht ertragen kann oder die Stimmen in meinem Kopf es mir befehlen.
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
672 Beiträge
 
Delphi 12 Athens
 
#7

AW: Wieso Speicheranforderung in Try...Finally ?

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

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 10:42
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.
Quellen?
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
672 Beiträge
 
Delphi 12 Athens
 
#9

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 10:50
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.
Quellen?
Na, dieser Thread. So hab ich hier die Hauptargumente für das try/finally jedenfalls verstanden: Auch im Fehlerfall werden die Ressourcen noch sauber freigegeben => das Programm wird robuster. Das Wort robuster schwirrte mir im Kopf rum, weil es HeZa in Beitrag #13 benutzt hat. Passt aber ganz gut zu dem, wie ich die Pro-Argumente bisher verstanden habe.

Bis denn
Bommel
  Mit Zitat antworten Zitat
Benutzerbild von Luckie
Luckie

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 16. Aug 2011, 12:01
Dass try-finally Fehler behandelt ist falsch. try-finally ist ein Ressourcenschutzblock und auch im Fehlerfall belegte Ressourcen wieder frei zu geben. Eine Fehlerbehandlung findet im Except-Block statt.
Michael
Ein Teil meines Codes würde euch verunsichern.
  Mit Zitat antworten Zitat
Antwort Antwort

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