Leaderboard

It appears that Marco lacks the technical understanding to evaluate this issue. I left a comment.

To be precise, you are using it to catch access to NILLED object pointers. And you believe this is a debugging tool. But really this is just debugging theater. Anyone using FreeAndNil to force AVs when the object reference is next used is de-facto claiming otherwise, and this is where you seem to have gotten lost in my explanation. A *LOT* can happen on a nilled object reference without creating an AV. Understanding why it is designed that way should be enough to answer your own questions about why you should not be abusing FreeAndNil as a debugging tool. There are purpose-built tools for catching use-after-free conditions. FreeAndNil is not one of them. I am just saying it is better to use the purpose-built tools for this instead of relying on a side-affect of FreeAndNil which can only catch use-after-free SOMETIMES. In the projects I work on where FreeAndNil is used everywhere (without need) I just assume that I cannot know for sure if those variables are actually intended to be used again or not. That's fine. In my own code I just make my intent clear by only using FreeAndNil when it is appropriate for the code -- not as a halfway debugging tool.

Using FreeAndNil is the very essence of https://en.wikipedia.org/wiki/Cargo_cult_programming

Code obfuscation: why is it being used? What is the intent? Why did the author of this code deem it necessary to assign free to a variable that appears to be going out of scope? What, as the maintainer, am I not understanding? Other than that, nothing. It's just a small waste of cpu cycles. EDIT: Actually, nilling an object reference with FAN can hide other logic errors such as some code path that could lead to free unintentionally being called a second time. Since free checks for a nil Self, it succeeds, even if it should lead to an AV due to an erroneous double-free. Depending on how that second call to free is reached you could be making it harder for the logic error to surface as an AV.

For D12 Computer\HKEY_CURRENT_USER\Software\Embarcadero\BDS\23.0\WelcomePage\gksoft For D11 Computer\HKEY_CURRENT_USER\Software\Embarcadero\BDS\22.0\WelcomePage\gksoft

Real life race condition :-)

Instead of FreeAndNil implying a certain pattern I think it would be better to explicitly state, in a comment, when and why a certain behavior is expected. The projects I'm working on right now has something in the neighborhood of 200 calls to FreeAndNil in it. All except two are there to catch stale pointers; FreeAndNil gives us a nice AV that we can easily debug. Free would most likely give us a sporadic random error somewhere else. The two remaining cases are in a framework where we need a container var to be nilled before the object is destroyed. I won't go into why it's necessary; I'm sure you know the pattern. Anyway, for these two cases, the comments in the code clearly document why the FreeAndNil pattern is necessary. This is an old project and the introduction of FreeAndNil, where it makes sense of course, has helped us catch and eliminate countless bugs. Before I took over as the lead the code was littered with hundreds of empty try..except blocks simply because they had given up on trying to find the cause of the exceptions.

Use it ONLY when you NEED it. When freeing an object that is pointed at by a given pointer variable, and that variable may be used again later, then nil'ing that variable makes sense, as future code will be sensitive to what the variable is (or is not) pointing at. But, if the pointer variable is not going to be used after freeing the object, then there is simply no point is nil'ing the variable.