Befehlszeile ausführen

[DeddyH]

Ich verstehe nicht, auf welchen Code-Teil Du Dich beziehst. Wo wird nach einem Fehler einfach weitergemacht? Bin ich blind?

[idefix2]

@ Himitsu
Im Prinzip gebe ich Dir ja Recht, dass man mögliche Fehler mit try finally abfangen sollte, bei dem von Dir jetzt genannten Beispiel bin ich ganz bei Dir.
Bei einem tstringlist.create erscheint es mir nicht sinnvoll

@deddyh
Wenn vorher nicht nil zugewiesen wird, kann das nur zu Problemen führen, wenn tstringlist.create eine Exception liefert. Und den Fall zu berücksichtigen und irgendwie abzufangen ist eben meiner Meinung nach unnötig, weil das Programm dann nichts sinnvolles mehr produzieren kann, wenn es weiterläuft.

Ich würde es so machen:

Delphi-Quellcode:

output := TStringList.Create;
errors := TStringList.Create;
try
  ...
finally
  output.free;
  errors.free;
end;

Wenn das Erstellen der Stringlist eine Exception liefert, dann geht ohnehin nichts mehr. Und dann wird gleich die richtige Exception angezeigt.

[himitsu]

Zitat:

Zitat von idefix2 (Beitrag 1065325)

Wenn schon ein tstringlist.create abstürzt, wird es sowieso bei nächster Gelegenheit knallen. Derartige Fehler abfangen und weitermachen, als wäre nichts gewesen, bringt doch gar nichts.

Nicht?
Es kann doch zufällig danach noch was freigegeben werden und dann paßt es wieder.

Delphi-Quellcode:

errors := nil;
output := GetMem(1000000000);  // grade noch genug
try
  errors := GetMem(100);  // das war jetzt zuviel
  ...
finally
  FreeMem(errors);  // hier könnte es ohne :=nil nochmals knallen
  FreeMem(output);
end;

Jetzt könnte es ab dem nächten Except (von einem Try-Except) weitergehn, da wieder genug Speicher frei ist.
Ohne das :=nil könnte es aber passieren, daß es beim

Delphi-Quellcode:

FreeMem(errors)

nochmal knallt, dabei die ursprüngliche Fehlerursache/-adresse verfälscht und

Delphi-Quellcode:

FreeMem(output)

ganicht mehr ausgeführt wird.

du siehst ... ohne das :=nil wird es nur schlimmer und mit kann es besser werden



[add]

Zitat:

Delphi-Quellcode:

output := TStringList.Create;
errors := TStringList.Create;
try
  ...
finally
  output.free;
  errors.free;
end;

bitte nicht ... wenn es hier bei errors knallt, dann wird output nicht freigegeben.

[Assarbad]

Zitat:

Zitat von DeddyH (Beitrag 1065324)

Du liegst falsch. Free prüft intern auf nil ab, so dass nil-Objekte nicht zerstört werden, es folglich also auch nicht knallt.

Aber Säääähkunde mal. Ich denke Variablen werden in Delphi in vielen Fällen vorinitialisiert? Hier nicht? Warum? Danke.

[DeddyH]

IIRC gilt dies nicht für lokale Variablen.

[Assarbad]

Zitat:

Zitat von DeddyH (Beitrag 1065341)

IIRC gilt dies nicht für lokale Variablen.

Aaaaah. Jetzt hat's klick gemacht. Jupp, entsinne mich jetzt. Danke.

[DeddyH]

Sonst gäbe es die Warnung "Variable xyz ist möglicherweise nicht initialisiert worden" ja auch gar nicht, weil sinnlos ;)

[himitsu]

Globale Variablen (auf Heap?) werden initialisiert, da der gesamte Speicher anfangs eh null ist, welcher von Windows kommt.

Klassenfelder werden via ZeroMemory/FillMemory+0 in CreateInstance des Objekts genullt.

Lokale Variablen (auf'm Stack) werden nicht initialisiert (abgesehn von sowas wie String/Interface/DynArray, welches immer initialisiert wird)