Of course you should not write code that tries to access objects that you have released. So in a perfect world, setting a pointer to nil after you release the object is not necessary. But being an imperfect programmer, I find it to be a useful failsafe mechanism and one that does not require a lot of effort.

We should not get confused that the object to which foostring pointed is still in memory.
we have just lost the reference to obj1 by setting as nil and since its refcount was 2 after obj2’s retain, and refcount of foostring is 1 after calling the release and setting it as nil.
Although if the code is upto this only, i doubt that the object allocated actually still have a refcount 1. and we have set the obj1 to nil so we have actually lost its reference and cant further send release to reduce refcount to zero.

Isn’t it a leek in that case.
However we are nt discussing leak here but i doubted it.
What are your comments to that.

I do still stand by my statement that it’s generally preferable to crash rather than silently message nil. Unless your program is setup in such a way that messages to nil are part of the program logic.

Wrong. You’re confused about pointer copies. When objectOne passed fooString to objectTwo, it passed a *copy* of the fooString pointer. At this point objectOne has a copy of the fooString pointer, and objectTwo has its own distinct copy of the fooString pointer as well. Therefore, when objectOne sets its copy to nil, there is no effect on objectTwo’s copy.

1) objectOne creates an NSString via [[NSString alloc] init]. This NSString object now has a retain count of 1
2) objectTwo is passed the NSString* and calls retain on it, the NSString object now has a retain count of 2
3) objectOne is done with the NSString and calls release on it, the NSString object now has a retain count of 1. Setting the NSString* to nil is perfectly safe here
4) objectTwo tries to do an operation on the string, which still has a retain count of 1, thus this is perfectly okay.

Since Objective-C uses a reference counting system to keep track of memory, it’s very easy to see how the following scenario could play-out:
1) objectOne creates an NSString (i.e. NSString* fooString = [[NSString alloc] init];)

2) objectTwo is passed fooString, and calls [fooString retain]; because it’s using the string, and needs it around.

3) objectOne is done with fooString, and so calls [fooString release]; Now, by your suggestion, it also does fooString = nil;

4) objectTwo tries to do an operation on fooString, but since objectOne set it to nil, the operation fails, and SILENTLY (because as you state, messages to nil are perfectly valid). Now you have no idea why objectTwo isn’t working correctly, and worse fooString may be been set to nil some time earlier, maybe even several run loops earlier, so it will be very difficult to figure out what’s going wrong. It can also be extremely difficult to figure out what object is setting fooString to nil in the first place.

In a reference counting memory management system, it’s much smarter to let the run time do it’s job, and keep track of those references. If a fully released object is called you know immediately why the crash occurred, and then you just need to figure out where your reference counting went wrong.

One more thing, often times when a memory mis-management crash occurs the debugger will show objects you thought were one type as a different type entirely. For example, something you though was a UIImage will show as an NSString in the debugger. For this same reason it’s also common to get “Object Does Not Recognize Selector” crashes, becuase your sending UIImage methods to an NSString (again, for example).

I hope you can see my point of view as a better choice than setting variables to nil.