Zitat von
negaH:
Die einzige Legitimation für FreeAndNil() statt einfachem .Free ist eben der Fakt das FreeAndNil() vor der Freigabe des Objektes die Objektreferenz auf nil zurücksetzt, neben dem Punkt das es ein Einzeiler im Source ist.
Warum soll eine Referenz auf ein Objektfeld *in einem Destruktor* auf nil gesetzt werden? Denn schliesslich soll danach kein Zugriff mehr auf das Feld erfolgen. Wenn dennoch eine Methode auf dieses Feld zugreifen will, dann ist das das im Thread gemeinte 'bad design'.
Wenn bei Verwendung von FreeAndNil() im Destruktor (nur darum geht es!) der nachfolgende Zugriff auf das freigegebene Feld an anderen Stellen mit "if Assigned()" abgesichert wird, wird keine AccessViolation ausgelöst. D.h. man verwendet zwei für sich genommen sinnvolle Konstrukte zur 'defensiven' Codierung, die zusammen dann aber einen Fehler verdecken.