2 StringListen try finally richtig anwenden

[hoika]

Hallo,
irgendwann hatte ich hier mal gelesen, dass der folgende Code richtig ist

Delphi-Quellcode:

var
  SL1, SL2: TStringList;
begin
  SL1 := nil;
  SL2 := nil;
  try
    SL1 := TStringList.Create;
    SL2 := TStringList.Create;
  finally
    FreeAndNil(SL1);
    FreeAndNil(SL2);
  end;

Grund: Wenn hinter SL1 := TStringList.Create; was passiert, werden beide StringListen korrekt freigegeben ,
genauer SL1 wird freigegeben, SL2 ist ja noch nil;

Jetzt habe ich den Code aber mal durch den PAL (Pascal Analyzer) gejagt und der sagt, dass das
SL1 := nil;
SL2 := nil;
unnützer Code ist.

Vorgeschlagen wird

Delphi-Quellcode:

var
  SL1, SL2: TStringList;
begin
  SL1 := TStringList.Create;
  SL2 := TStringList.Create;
  try
  finally
    SL.Free);
    SL2.Free;
  end;

Was meint ihr?

[TRomano]

Delphi-Quellcode:

var
  SL1, SL2: TStringList;
begin
  SL1 := TStringList.Create;
  SL2 := TStringList.Create;
  try
    // tue irgendetwas
   finally
    FreeAndNil(SL1);
    FreeAndNil(SL2);
  end;

Wohl dann eher so (Erzeugung der Klassen außerhalb von try ... finally ... end). Über FreeAndNil() wollen wir hier nicht diskutieren ...

[mkinzler]

Zitat:

was passiert, werden beide StringListen korrekt freigegeben ,
genauer SL1 wird freigegeben, SL2 ist ja noch nil;

Free prüft, ob das Objekt existiert.

Da die Methode/Prozedur danach sowieso beendet wird ist das Setzen auf Nil nicht unbedingt nötig.

[Der schöne Günther]

Zitat:

Zitat von TRomano (Beitrag 1341183)

(...)

Das ist zwar schon ziemlich theoretisch (was soll bei einer TStringList schon schief gehen?), aber wenn der Konstruktor von SL2 fehlschlägt bleibt SL1 ewig im Speicher...

[Neutral General]

Also hiermit kannst du nix falsch machen, aber auch ich mache das nicht immer :mrgreen:

Delphi-Quellcode:

var
  SL1, SL2: TStringList;
begin
  SL1 := TStringList.Create;
  try
    SL2 := TStringList.Create;
    try
      // Code
    finally
      FreeAndNil(SL2);
    end;
  finally
    FreeAndNil(SL1);
  end;
end;

[TRomano]

Bei Mehrfach-Erzeugungen hast Du natürlich Recht ... man kann es noch weiter "Theorisieren" und das Ganze noch in ein

Delphi-Quellcode:

try ... except ... end

einbetten.
Und bei einfachen Klassen wie TStringList läuft sicherlich nichts schief.

[Sir Rufo]

Zitat:

Zitat von mkinzler (Beitrag 1341184)

Free prüft, ob das Objekt existiert.

Seit wann geht das denn? :gruebel:

Ich war immer der Meinung, dass

Delphi-Quellcode:

Free

prüft ob

Delphi-Quellcode:

Self = nil

ist und nicht mehr.

Eine lokale Variable ist immer nicht initialisiert und kann jeden beliebigen Wert enthalten. Um einen bestimmten Wert zu garantieren muss die Variable initialisiert werden.

Es muss also minimal so aussehen um sicher zu sein, egal was irgendein Analyzer da von sich gibt

Delphi-Quellcode:

procedure foo;
var
  sl1, sl2: TStringList;
begin
  sl2:= nil;
  sl1:= TStringList.Create();
  try
    sl2:= TStringList.Create();
    ...
  finally
    sl2.Free();
    sl1.Free();
  end;
end;

[DeddyH]

https://forum.delphi-treff.de/index....-verschachteln

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1341191)

https://forum.delphi-treff.de/index....-verschachteln

Beim Test aber bitte aufpassen, ich hatte in so einer lokalen Variablen auch schon die Referenz zum MainForm drin => Keine Exception aber aber das Programm war auch beendet :stupid:

[Rollo62]

Ich initialisiere die Variablen auch meistens direkt nach begin, und bekomme diese blöden Compilermeldungen
das dies überflüssig sein.
Aber wenn es überflüssig ist, dann müssten ja alle Variablen schon vorinitialisiert sein.

Delphi-Quellcode:

procedure foo;
var
  sl1, sl2: TStringList;
begin
  //<-- Ist ab hier sl1 und sl2 hier nicht auch schon mit nil initialisiert, also SOLLTE nichts passieren ?
  sl1:= TStringList.Create();
  //--> passiert hier eine Exception ist sl2 = nil ?
  sl2:= TStringList.Create();

  try
    ...
  finally
    sl2.Free();
    sl1.Free();
  end;
end;

Kann man sich etwa darauf verlassen ?
Oder was sollen die Meldungen dann bedeuten (womöglich einfach nur bugs ?


Rollo

[bra]

Zitat:

Zitat von DeddyH (Beitrag 1341191)

https://forum.delphi-treff.de/index....-verschachteln

Auch wenn es vielleicht nicht sauber ist, verwende ich immer die Variante

Delphi-Quellcode:

v1 := xxx.create;
v2 := xxx.create;
try
finally
  v1.Free;
  v2.Free;
end;

Mal ehrlich, mit noch mehr verschachtelten try...finally's wird der Code einfach nur grausam unübersichtlich. Und wenn schon beim Create eine Exception auftritt, ist eh irgendwas ganz gewaltig im Argen.

[Sir Rufo]

Meine Klassen haben im Create so gut wie immer einen Guard Abschnitt, der eine Exception wirft, wenn die Argumente im Create unsinnig sind, meine Klasse mit diesen Werten gar nicht arbeiten kann.

Ein Create ist auch nur eine gewöhnliche Methode die auch eine Exception werfen kann. Wenn ich nicht auf MemLeaks stehe, dann implementiere ich es richtig (das eben keine MemLeaks entstehen können).

[Sir Rufo]

@Rollo62

lokale Variablen sind per Definition nicht initialisiert. Man kann sich bezüglich des Wertes auf gar nichts verlassen. Die Compilermeldung ist in diesem speziellen Fall Schwachfug

[himitsu]

Initialisieren muß man Variablen (vorallem die Lokalen) nur, wenn man sie auswerten will/muß, bevor etws zugewiesen werden konnte.

Grundsätzlich:
* Alle Variablen müssen vor dem Try initialisiert werden (gilt vorallem für lokale Variablen)
* maximal 1 Create dürfte vor das Try (wenn es da schon knallt wird Nachfolgendes nicht ausgeführt)
* im Free kann man nur etwas zusammenfassen, wenn es dort keine Fehler geben kann, bzw. maximal beim letzten Befehl da drin

Also ob sich mehrere Try-Finally verbinden lassen, hängt eigentlich vom Finally ab, aber man kann Try-Finally auch da unten verschachteln.

Zitat:

Delphi-Quellcode:

procedure foo;
var
  sl1, sl2: TStringList;
begin
  sl2:= nil;
  try
    sl1:= TStringList.Create();
    sl2:= TStringList.Create();
    ...
  finally
    sl2.Free();
    sl1.Free();
  end;
end;

sl1 wurde nicht initialisiert und es knallt im finally, wenn es schon beim

Delphi-Quellcode:

sl1:= TStringList.Create();

Probleme gibt.

Delphi-Quellcode:

sl1 := nil;
sl2 := nil;
try
  sl1 := TStringList.Create;
  sl2 := TStringList.Create;
  ...
finally
  sl2.Free;
  sl1.Free;
end;

Delphi-Quellcode:

sl1 := TStringList.Create;
try
  sl2 := TStringList.Create;
  ...
finally
  sl2.Free;
  sl1.Free;
end;

Delphi-Quellcode:

sl1 := TStringList.Create;
try
  sl2 := TStringList.Create;
  ...
finally
  try
    sl2.Free;
  finally
    sl1.Free;
  end;
end;

Delphi-Quellcode:

sl1 := TStringList.Create;
try
  sl2 := TStringList.Create;
  try
    ...
  finally
    sl2.Free;
  end;
finally
  sl1.Free;
end;

Letztendlich bassiert alles auf den oben genannten Punkten.
Also wenn die zutreffen, dann isses OK.

Selbst das wäre "richtig"

Delphi-Quellcode:

sl1 := TStringList.Create;
try
  sl2 := TStringList.Create;
except
  sl1.Free
end;
try
  ...
finally
  try
    sl2.Free;
  finally
    sl1.Free;
  end;
end;

// oder

sl1 := nil;
try
  sl1 := TStringList.Create;
  sl2 := TStringList.Create;
except
  sl1.Free
end;
try
  ...
finally
  try
    sl2.Free;
  finally
    sl1.Free;
  end;
end;

z.B. bei einer TStringList geh ich grundsätzlich davon aus, daß das Freigeben immer funktioniert (so lange der Zeiger gültig ist)
und demnach kann ich da auch mehrere Free zusammen in ein Finally schreiben.

Sollte es dort dennoch knallen, dann ist perse das Programm nicht mehr lauffähig und eine bessere Fehlerbehandlung ist eh nicht mehr nötig. (z.B. nach einem Buffer-Overrun)

[Rollo62]

Das sehe ich auch so.
Allerdings beim Debuggen scheinen die Variablen bei Objekten (immer ?) korrekt genullt zu sein,
hab allerdings nicht getestet ob das generell so ist.
Bei anderen Variablentypen ist das jedenfalls nicht der Fall.

Ich dachte es gäbe dazu vielleicht eine globable Compilereinstellung.

Leider kann man die "unützen" Hints nicht gezielt abschalten, nur evtl. mit einem {$HINTS Off} vor solchen Funktionen, was aber auch nicht machen möchte.
Mich stören die Dinger jedenfalls gewaltig.

Rollo

[Sir Rufo]

@himi :thumb:

(hab mal still und heimlich meinen Beitrag editiert, evtl. merkt es ja keiner :stupid:)

[himitsu]

Debuggen: Wenn es gibt einige Typen, die werden automatisch initialisiert. (z.B. strings)

Und dann kommt es halt darauf an wo diese Variablen liegen (auf'm Heap, also z.B. Global oder in einer Klasse) oder auf'm Stack und ob oder was vorher an der Stelle gespeichert war.

[hoika]

Hallo,
das Verschachteln hatte ich früher auch gemacht, aber:
wie Sir Rufo richtig sagt, das wird unübersichtlich,
trotz 250 Zeichen pro Zeile ;)

Wir haben jetzt eine neue Version von PAL bestellt,
mal sehen, was der so anzeigt ...

< Leider kann man die "unützen" Hints nicht gezielt abschalten, >
< nur evtl. mit einem {$HINTS Off} vor solchen Funktionen, was aber auch nicht machen möchte. >
< Mich stören die Dinger jedenfalls gewaltig. >
Dann jag mal dein Projekt durch den PAL, der zeigt dir Sachen an ...
Also ich finde die Hints gut.
Ich versuche immer, die gegen 0 Laufen zu lassen.

[Lemmy]

Zitat:

Zitat von Rollo62 (Beitrag 1341217)

Leider kann man die "unützen" Hints nicht gezielt abschalten, nur evtl. mit einem {$HINTS Off} vor solchen Funktionen, was aber auch nicht machen möchte.
Mich stören die Dinger jedenfalls gewaltig.

dann sorge dafür, dass nach dem Compilieren keine "unnützen" Hinweise erscheinen, einen Teil davon kannst Du über die Einstellungen abschalten (bei uns z.B. Plattformsymbol/unit) Wir haben hier schon lange im Buildsystem die Einstellung, dass auch bei Hints eine Warnung an den Comitter raus geht, eine Warnung des Compilers führt zu einem Build-Fehler. Und gerade der Hinweis auf eine Zuweisung die "nicht genutzt wird" hat mich schon das eine oder andere mal auf einen Strukturfehler hingewiesen. Wenn da noch 10, 20 weitere Hinweise erscheinen,dann wird keiner davon beachtet....

den PAL nutze ich leider immer noch viel zu wenig, den finde ich an vielen Stellen ebenfalls eine große Hilfe.

[Rollo62]

Genau das versuche ich ja auch, aber wenn ich aus meinem Sicherheitsverständnis heraus lieber eine
Variable mehr als nötig initialisiere, dann sollte diese Warnung nicht kommen.
Z.B. setzte ich schonmal Result := False; o.ä. pro Forma im Funktionkopf, und kann dann sicher sein
das später nichts crasht.

Es könnten ja auch mal Fehler im Compiler auftauchen (womöglich sind aber jetzt schon fehler drin),
wo dann uninitialisierte Variablen herumhängen würden, genau dem will ich vorbeugen.
Das wird extrem schwierig zu finden, falls soetwas mal in Delphi 10.xx Yokohama auftritt.

Generell habe ich auch alle Warnings und Hints an, und ich räume nachher auch immer auf.

Es gibt übrigens auch immer Warnings/Hints in Drittkomponenten die man nicht so einfach los wird.
Auch das wäre ein Grund das mal gezielt abschalten zu können, warum nicht genauso wie bei den Warnings ?


Rollo