Versteh ich nicht, bzw. das ist unlogisch.
zwei Szenarien:
1.) Objekt.Free lösst
Exception aus:
Wird stattdessen mit FreeAndNil(Objekt) gearbeitet wird es denoch diese
Exception geben. Ich wüsste nicht das FreeAndNil() intern Exceptions abfängt. So oder so wird man also eine
Exception bekommen, wenn sie in .Free auftritt dann auch in FreeAndNil(). Der Fall das Objekt = nil ist mal aussen vorgenommen da FreeAndNil() identisch zu if Objekt <> nil then Objekt.Free ist.
2.) nach Objekt.Free wird
Exception ausgelösst aber bei FreeAndNil() nicht mehr.
Sicheres Indiz dafür das das Program im späteren Ablauf nochmals auf Objekt zugreift obwohl es zerstört wurde. Der Programmierer hat aber schon Vorsorge beim Zugriff auf Objekt mit Assigned(Objekt) getroffen.
Damit lösst FreeAndNil() definitiv und sauber das entstandene Problem. Mehr noch, da FreeAndNil() die Objektreferenz vor dem .Free Aufruf erstmal in eine temp. Variable kopiert und sofort die Referenz auf nil setzt, vermeidet FreeAndNil() eine Kaskade von Fehlern beim Aufruf von .Free. Es ist also sicherer als das Equivalent von
Delphi-Quellcode:
if Objekt <> nil then
begin
Objekt.Free;
Objekt := nil;
end;
Wenn nämlich Objekt.Free eine
Exception auslösst dann wird die Variable nicht mehr auf nil gesetzt. Das macht FreeAndNil() anders. Eigentlich müsste die Funktion NilAndFree() heissen.
Welche anderen Fehlerquellen für Objekt.Free im Unterschied zu FreeAndNil() sollte es noch geben ?
Alle anderen Exceptions können wir ausklammern und könnten Designfehler sein, richtig, aber sie haben nichts mehr mit Objekt.Free und FreeAndNil() im Zusammenhang gesehen zu tuen.
Ergo: dämliche Diskussion da es keinen Bezug von FreeAndNil() im Unterschied zu Objekt.Free zu einem Designfehler gibt. Denn wenn Designfehler die Ursache des Problems sein sollten dann werden sie mit FreeAndNil() genauso wenig gelösst wie mit einfachem Objekt.Free. Auch wenn dann bei FreeAndNil() erstmal scheinbar eine spezifische
Exception nicht mehr auftritt so ist denoch das Program garnicht darauf vorbereitet mit Objektrefernezen die nil sind umzugehen und wird später eben dort Exceptions auslösen, eben Designfehler. Es ist also irrelevant ob man Objekt.Free im Vergleich zu FreeAndNil() betrachtet, der Designfehler wäre die Ursache und daran muß man arbeiten.
Nun, wenn das die Kernaussage der ganzen Diskussion sein sollte dann sage ich nur -> trivial, das sollte jeder halbwegs logisch denkende Mensch sofort begriffen haben. Beseitige die Ursache des Problems statt an den Symptomen rumzudoktern (naja, unsere Prolitiker machen das ja nur so).
Gruß Hagen