Da brauchst'e eigentlich keine Sorgen haben.
Eine "Kopie" des Strings geht ja in die Funktion und danach wird dann das Ergebnis in die Stringliste geschrieben.
Und da du den alten Zeileninhalt danach nicht mehr braucht, kann man ihn also problemlos gleich ersetzen.
Das
Liste := TStringlist.Create;
kannst du zwar auch erst in dem Try-Finally machen, aber dann mußt du vor dem Try zumindestens die Variable initialisieren,
so wie es dir bestimmt der Compiler auch in seinen Meldungen gesagt hat.
Grund: Wenn es vor dem Create knallt, wäre die Variable nicht initialisiert und das Free im Finally könnte knallen, aufgrund einer ungültigen Klasseninstanz.
Oder noch schlimmer, wenn der Wert zufällig dem Instanzzeiger irgendeiner Klasse übereinstimmt, dann ist diese Instanz plötzlich weg und es knallt womöglich ganz wo andes irgendwann mal.
Nja, ich weiß jetzt nicht genau was das Burn macht, aber wenn es bei dem Befehl knallen täte, dann würde das Free danach nicht mehr ausgeführt.
Wenn es unbedingt zum Aufräumen nötig ist, dann nochmal ein Try-Except oder Finally drumrum, damit das Free sicher ausgeführt werden kann.
Aber ich hoffe mal die haben beim Destroy dafür gesorgt, daß immer ordentlich aufgeräumt wird, selbst ohne daß das Burn ausgeführt wurde (weil es voher knallte), drum isses einfach vor's Finally gerutscht.
PS: Statt MessageDlg kannst du auch die exceptiondialoge vom Delphi benutzen.
ShowException (SysUtils) ist der Dialog der
RTL
Application.ShowException ist der Dialog der
VCL
Application.HandleException wendet sich entweder Application.ShowException oder ShowException
Delphi-Quellcode:
try
...
except
Application.HandleException(Self); // oder nil, wenn es keine Owner-Klasse gibt
end;
Uber
on E: Exception do E.Message := 'Böser Fehler in Xyz: ' + E.Message;
kann man die Meldung erweitern.
Wenn man sich an ApplicationHandleException oder ApplicationShowException (Classes) wenden würde, nur leider gibt es dafür keinen "sicheren" einstieg.
Das macht sich übrigens besser, wenn man mal global
Exception-Dialoge ausblenden will/muß (z.B. beim Umbau auf eine Server-App), oder sie zumindestens ersetzen möchte, so wie es z.B. EurekaLog und MadExcept machen, indem sie ihre eigenen erweiterten Dialoge anzeigen.
Delphi-Quellcode:
try
...
except
if Assigned(ApplicationHandleException) then
ApplicationHandleException(Self)
else if Assigned(Application) then
Application.HandleException(Self)
else
ShowException(ExceptObject, ExceptAddr);
end;
Delphi-Quellcode:
try
...
except
if Assigned(ApplicationShowException) then
ApplicationShowException(ExceptObject)
else if Assigned(Application) then
Application.ShowException(ExceptObject)
else
ShowException(ExceptObject, nil);
end;
k.A. warum Borland/Codegear/Embarcadero das nicht schön in einer Funktion gekapselt haben, damit man sich richtig und vorallem einfach an die Exceptionbehandlung wenden kann.
Application.ShowException zeigt die Meldung immer an
und Application.HandleException ignoriert einige Exceptions (z.B. EAbort), wendet sich ansonsten erstmal an Application.OnException und seit erst dann die
Exception an, oder auch nicht ... jenachdem, ob und wie man die
Exception "behandelt".
Also einfach immer an Application.HandleException wenden.
Da kann man dann entweder alle Exceptions global im OnException (TApplication oder TApplicationEvents) loggen und oder ausblenden.