There is a lot of talking about the usage of FreeAndNil in destructors. I’ve never thought about it before so I used it quite often even in destructors. Although I don’t use it as a universal remedy function, it still seems to be a bad design: a thought shared by many leading Delphi experts.  Thus I refactored the destructors in JWSCL to accompany them.

I introduced a function similar to FreeAndNil

procedure JwFree(var Obj);

It just frees an object…in the release build of an application. However, in a debug build it additionally sets the value of obj to $C which isn’t a valid memory address. So “Assigned” won’t work here.
Any access to this “freed” member will generate an AccessViolation at address $0000000C. So you will know that a member of JWSCL was used beyond its life time.

procedure JwFree(var Obj);
var
 Temp: TObject;
begin
  Temp := TObject(Obj);
{$IFDEF DEBUG}
  Pointer(Obj) := Pointer($C);
{$ENDIF DEBUG}
  Temp.Free;
end;

I wonder if it should be extended to support different flavors like

  1. $C in debug build and don’t touch the value in release (as currently shown)
  2. Set the value $C also in release mode.
  3. Nil the value in release mode. (quiet death mode)

They could be set by a compiler switch. Still have to think about this though…
What do you think?

Changes

I have commited these changes into the developer branch. They will be published in a next release so the current release won’t break a bad design.

:-)