Frage zu FreeAndNil

[negaH]

@himitsu:

Ist mir bewusst das .Free intern Self auf nil prüft, das muß aber nicht für selber geschriebene Destruktoren gelten. Zudem bezog sich mein Assigned(Objekt) ja eher auf die anderen Zugriffe auf solche Objektreferenzen die auch nil sein könnten.

@Michael:

Genau so habe ich das auch heraus gelesen und exakt deswegen bezweifle ich die Sinnhaftigkeit dieser Diskussion. Denn FreeAndNil() im Vergleich zu native .Free hat nichts mit den Fehlerursachen geschweige denn mit der Art&Weise der Programmierung noch Fehlersuche zu tun.

Die letzendliche Schlußfolgerung die ein unbedarfter Entwickler aus dieser Diskussion ziehen würde ist doch das man mit FreeAndNil() vorsichtig sein sollte, und das ist falsch, egal in welchem Kontext man FreeAndNil() statt .Free benutzt.

Falls es designtechnische Probleme mit .Free und FreeAndNil() gibt, die schlußendlich deren Existenzberechtigungen betreffen, dann kann das nur ein Problem der Feature der Programmiersprache sein. Dann wäre die Diskussion auch sinnvoll.

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.

Gruß Hagen

PS: benutzt man FreeAndNil() statt .Free und hat den Designfehler gemacht das man im restlichen Program immer davon ausgeht das die Objektreferenz garnicht nil sein darf dann wird man Zugriffsschutzverletztungen bekommen die als Addresse 0x0000000?? angeben statt irgendeine Speicheradresse. Das ist für einen erfahrenen Entwickler der sofortige Hinweis das man irgendwo im Source auf ein "nil-Objekt" zugreift, ergo wesentlich konstruktiver für die Fehlerbeseitigung. Betrachtet man nun in diesem Zusammenhang noch den Fakt das die Speicherverwaltung freigegebene Speicherbereiche gleicher Größe sofort wieder verwendet dann kann es ohne FreeAndNil(), und späteren fehlerhaftem Zugriff auf ein nicht mehr existentes Speicherobjekt, dessen ehemaliger Speicherbereich nun schon längst wieder für ein anderes Objekt benutzt wird, noch zu viel wilderen und schwerer zu findenen Fehlern kommen. Ein weiteres Argument pro FreeAndNil().