2 StringListen try finally richtig anwenden

[bra]

Zitat von DeddyH:

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

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

[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 von Rollo62:

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