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 von TRomano:

(...)

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

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 try ... except ... end einbetten.
Und bei einfachen Klassen wie TStringList läuft sicherlich nichts schief.

[Sir Rufo]

Zitat von mkinzler:

Free prüft, ob das Objekt existiert.

Seit wann geht das denn?

Ich war immer der Meinung, dass Free prüft ob 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 von DeddyH:

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

[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