Befehlszeile ausführen

[himitsu]

Nee, wieso soll es da knallen?
Free prüft ja auf NIL und überspringt dann das Freigeben.
(unter Anderem soll man darum ja auch vorzugsweise .Free und nicht direkt .Destroy aufrufen)
[add]ahhhh, wo kommen denn die Beiträge her ... und DeddyH zustimm[add/]

Nja, es geht mehr ums Prinzip. Klar kann bei diesem einfachen TStringLst.Create nicht viel passieren und wenn, dann ist wirklich Vieles schon verloren, aber was ist, wenn in dem Create mal mehr passiert?

Beispiel: fs := TFileStream.Create('dateina.me', ...); ... wenn es hier z.B. wegen fehlenden Rechten knallt und dann diese Fehlermeldung durch die nachfolgend auftretende Speicherzugriffsverletzung verdeckt wird, dann hat man ein Problemchen.
(bei dieser lokalen Variable ist die Chance immerhin nur 1 zu 4 Milliarden, daß diese Variable zufällig schon nil ist)
OK, der Debugger hält vielleicht noch bei der ersten Exception kurz an, aber ohne Debugger sieht man nur noch die letzte Exception.


[add]
Auch wenn bei soeinem einfachem und dennoch extremen Einzelfall eh alles egal ist,
sollte man dennoch eine einheitliche Behandlung implementieren.
Wenn man es immer so/gleich macht, dann vergißt man es an anderen Stellen nicht, wo es dann mal nicht mehr egal sein könnte.

PS: Das Zweite ist nur eine kleine zusätzliche Zeile, ein einziger extrem kurzer ASM/CPU-Befehl und belegt nur sehr wenige Bytes in der EXE, aber es kann eine sehr große positive Wirkung haben.

[himitsu]

Zitat von idefix2:

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 FreeMem(errors) nochmal knallt, dabei die ursprüngliche Fehlerursache/-adresse verfälscht und 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.