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 2 von 5     12 34     Letzte » 
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.289 Beiträge
 
Delphi 10.4 Sydney
 
#11

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 12. Aug 2011, 22:03
@FredFesl

So selbstbewußt hätte ich es nicht vortragen können, sehe das aber genau so.
Ansonsten müsste man (wenn man es genau machen wollte) beim Erzeugen von 10 Objekten nacheinander auch 10 verschachtelte Schutzblöcke erzeugen (für jedes Objekt einen).
Es kann ja jeder machen wie er will, aber der Sinn erschließt sich mir (in den meisten Fällen) nicht.


@WM_CLOSE+Luckie

Wenn ein Programm mit einem solch gravierenden Fehler wochenlang durchläuft, ist mit dem Ergebnis wohl ohnehin nix anzufangen.
Das gilt jedenfalls, wenn der Fehler nicht komplett bereigit wird (incl. aller Daten und Zustände).
Und diese Bereinigung kann man eigentlich nur gewährleisten, wenn man mit einem bestimmten Fehler rechnet, den man aber nicht unbedingt vermeiden kann (E/A-Funktionen).
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
40.503 Beiträge
 
Delphi 11 Alexandria
 
#12

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 12. Aug 2011, 22:23
Ich sage es mal so "schau dir meinen FileSplitter (hier in der DP) mal an.
weiter siehe *1


Ja, wenn nach einem Knall (Exception) sowieso alles zu spät ist, könnte man es auch gleich sein lassen ... Windows räumt ja auf.

Aber dennoch sollte man es in einem gewissen Maße machen, denn wenn man etwas immer gleich macht, egal ob das Programm wichtig oder nutzlos ist, dann hat man a) ähnliche Programmstrukturen (Wiederverwendbarkeit) und damit auch ein leichteres Arbeiten, da man sich nur an eine Struktur halten muß, was auch das Lesen/Verstehen vereinfacht
und wenn man dann durch das viele Programmieren dieses total verinnerlicht hat, dann kann man es an wichtigen stellen nicht so schnell vergessen.



*1 Ja, auch ich schreibe schonmal Programme ganz ohne Try-Finally, denn unter gewissen Umständen ist sowas garnicht nötig, da z.B. die WinAPI an vielen Stellen mit Fehlercodes arbeitet und nicht mit Exceptions.
Wenn es dort Probleme gibt, dann werden diese nicht gleich mit einer Exception quitiert und man kann/muß diese Fehler dann anderes behanden. (knallt es dort wirklich mal mit einer Exception durch, dann ist sowieso alles zu spät und jede weitere Bemühung eher umsonst)


Mit genügend Wissen/Erfahrung kennt man gewisse Schwachstellen oder auch Ecken, wo eigentlich nie was schief laufen kann ... in soeinem Kall kann man die Fehlerbehandlung auch schonmal etwas "anpassen".

Aber im Normalfall sollte man einfach alles Schützen, wenn man weiß ja nie was mal passiert ... ganz besonders bei Codes, welche man anderen zur Verfügung stellt.
siehe http://www.delphipraxis.net/162202-s...ml#post1116391
Das Original hieß
Delphi-Quellcode:
Result := '';
Parse := TStringList.Create;
Row := TStringList.Create;
try
  Parse.Text := GetBarcodesResult;
Was eigentlich auch schon sicher genug ist. (siehe meine Erklärung dort drüben)
Aber dennoch, ein gewisser (ausreichender) Schutz wird dennoch verbaut, auch wenn einige meinen könnten "wozu ... ist doch eh umsonst?".
Denn weißt du, ob der Code nicht mal in einem wichtigen Programm verbaut würde?
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list

Geändert von himitsu (12. Aug 2011 um 22:32 Uhr)
  Mit Zitat antworten Zitat
HeZa

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 03: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
samso

Registriert seit: 29. Mär 2009
434 Beiträge
 
#14

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 08:01
Ansonsten müsste man (wenn man es genau machen wollte) beim Erzeugen von 10 Objekten nacheinander auch 10 verschachtelte Schutzblöcke erzeugen (für jedes Objekt einen).
Verstehe ich nicht, in dem Thread "Bitte Warning erklären" wurden doch bereits Lösungen gezeigt, wie man die Verschachtelungen vermeiden kann. Auch die Behauptung "Wenn eine Exception auftritt, kann man alle weiteren Berechnung danach vergessen" stimmt doch so pauschal nicht. Das hängt doch stark von dem Kontext ab. Programme der Kategorie 24/7 haben da sicherlich andere Ansprüche, als ein Kommandozeilentool, dass nur mal schnell für eine spezifische Aufgabe zusammen gestrickt wurde.

Bei mir ist es eigentlich eher umgekehrt. Wenn in meinen Quelltext mal ein Schutzblock fehlt, dann ist das bei einer späteren Inspektion des Quelltextes immer ein Punkt, bei dem ich dann u.U. länger nachdenke, ob das an dieser Stelle tatsächlich legitim ist. D.h. ich verwende eventuell mehr Zeit bei der Wartung eines Quelltextes, wenn der Schutzblock fehlt, als wenn ich ihn konsequent einbaue.

D.h. der Schutzbock um "b.work" in dem Eingangs genannten Beispiel ist schon deshalb sinnvoll, weil ich bei der Wartung nicht in b.work reingehen muss um zu prüfen, ob da auch wirklich keine Exception auftreten kann.

Impliziert das Wort "Schutzblock" nicht schon, dass es sich um einen Security-Layer handelt? Und nein, ich kann mir keinen anderen sinnvollen Einsatz von Try-finally-Blöcken vorstellen, als genau diesen. Letztendlich ist es also die Frage, will ich auf Nummer sicher gehen, oder glaube ich, dass ich und alle anderen Verkehrsteilnehmer so gut sind, das niemals ein Unfall passieren kann (bzw. die Konsequenzen eines Unfalls sind mir einfach egal). Das muss jeder für sich entscheiden.
  Mit Zitat antworten Zitat
FredlFesl

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 09: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
FredlFesl

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 09:48
und wenn man dann durch das viele Programmieren dieses total verinnerlicht hat, dann kann man es an wichtigen stellen nicht so schnell vergessen....

*1 Ja, auch ich schreibe schonmal Programme ganz ohne Try-Finally, denn unter gewissen Umständen ist sowas garnicht nötig,...
Mit genügend Wissen/Erfahrung kennt man gewisse Schwachstellen oder auch Ecken, wo eigentlich nie was schief laufen kann ...

Aber im Normalfall sollte man einfach alles Schützen, wenn man weiß ja nie was mal passiert ... ganz besonders bei Codes, welche man anderen zur Verfügung stellt.
Also wird das Try-Finally immer angegeben, obwohl wir alle wissen, das es in diesem konkreten Beispiel vielleicht überflüssig ist, aber, hey, sicher ist sicher und außerdem schauen Kinder zu und da konnen wir nicht einfach sagen das man sich manchmal nicht schützen muss.

So, wie wenn wir immer erzählen, das man die Ampel nur bei 'grün' überqueren darf, aber: -unter uns-, wenn sonst keiner da ist, WTF.
Das Bild hängt schief.
  Mit Zitat antworten Zitat
HeZa

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 11: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 11:31 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Uwe Raabe
Uwe Raabe

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

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 11:34
Ich hätte da auch noch etwas Senf dazu: Es mag ja durchaus sein, daß zum Zeitpunkt der Programmierung das Freigeben eines Objekts auch nach einer Exception ziemlich egal ist. Das muss aber nicht für immer so sein. Ist zwar etwas konstruiert, aber man stelle sich vor, daß das Objekt eine externe Resource belegt (z.B. eine Server-Verbindung aufbaut, einen COM-Server startet oder einen Lizenzzähler hochzählt), die unter allen Umständen wieder freigegeben werden muss.

Der Punkt dabei ist, daß dieses Verhalten vielleicht erst später eingebaut wird oder womöglich erst zur Laufzeit bestimmt wird. Dann möchte man ja auch nicht alle Instanzen in allen Programmen durchgehen, ob die denn auch schön brav in ein try-finally geklammert sind.

Insofern ist ein try-finally Block etwas, daß mir womöglich meine zukünftige Arbeit erleichtert und mich vor meinen eigenen Fehlern schützt.
Uwe Raabe
Certified Delphi Master Developer
Embarcadero MVP
Blog: The Art of Delphi Programming
  Mit Zitat antworten Zitat
Benutzerbild von stahli
stahli

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
4.289 Beiträge
 
Delphi 10.4 Sydney
 
#19

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 11: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.459 Beiträge
 
Delphi 11 Alexandria
 
#20

AW: Wieso Speicheranforderung in Try...Finally ?

  Alt 13. Aug 2011, 12: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
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 07:23 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