What is the need of assigning 'nil' after releasing an object

Question

I usually release the object after use by

[myObject release];

But I found in some online tutorials that they assign a nil after releasing the object. Like

[myObject release];
myObject = nil;

Is it required?

possible duplicate of [Why set object to nil after sending release message in Obj-C](http://stackoverflow.com/questions/3072003/why-set-object-to-nil-after-sending-release-message-in-obj-c) — jscs, Feb 14 '12 at 18:55
Other candidates: [Set pointers to nil after release](http://stackoverflow.com/q/1418999/) [Is it necessary to set pointers to nil after release](http://stackoverflow.com/q/803531/) [When to set object references to nil](http://stackoverflow.com/q/1670876/) [Difference between release and release, then set to nil](http://stackoverflow.com/q/2809603/) — jscs, Feb 14 '12 at 19:06

score 29 · Accepted Answer · answered Feb 14 '12 at 11:41

It's a long-running debate as to whether setting the pointer to nil after releasing is necessary, but I come down on the side of it being a good idea.

After the object is released, the pointer you hold to it still points to the same place. If your release has taken the retain count to 0 then the object will be deallocated. If you then try and send a message to the deallocated object you'll get an EXC_BAD_ACCESS error. However, sending a message to the pointer after it's been set to nil won't error - it just won't do anything.

The other side of the argument is that if you're messaging a deallocated object it's good to know about it and fix your code to make sure it doesn't happen.

There are smart people in both camps.

score 3 · Answer 2 · answered Feb 14 '12 at 11:39

3

No, it is not strictly required.
If your code is well-structured there's no need to force myObject to be equal to nil.

However it may be a good habit: release does not immediately destroy the object, just decrease the retain count. Thus it may be,that, even if you call release, the object will still be there for a while, creating problems if you try to send it messages.

Using myObject = nil; eliminate this problem, since, even if you send a message to myObject nothing will actually happen.

answered Feb 14 '12 at 11:39

Manlio

10,768
9
50
79

3

I can only add this [great blog post by Jeff Lamarche](http://iphonedevelopment.blogspot.com/2010/09/dealloc.html). Which is an interesting read. – rckoenes Feb 14 '12 at 11:42
If the retain count would go to zero on a release the object is destroyed. But the memory is not cleared so it may appear to still be there. Only the pointer value is set to zero. The protection is that if another part of the code is referencing through the pointer and the pointer is nil nothing bad will happen, note that this covered a bug in the code!. There is another possibility, assign (id)0x42 so that there will be an immediate crash if there is an accede through the pointer by error,then the code can be fixed. – zaph Feb 14 '12 at 12:08

score 2 · Answer 3 · answered Feb 14 '12 at 11:40

It is not required, but mostly a style issue. Assigning nil after the release ensures, that you cannot accidentally use the released reference again (which may or may not result in a crash). Simply calling release on the reference may make the underlying memory go away. However, the pointer will still point to the (now potentially invalid) address, and the result of a subsequent method invocation using that pointer are undefined.

score 2 · Answer 4 · answered Feb 14 '12 at 11:40

No, it's not required.

It's a safety thing. If you have

[myObject release];

and then somewhere else you do

[myObject doSomething];

Then you will get problems.

If you have

[myObject release];
myObject = nil;

and then somewhere else you do

[myObject doSomething];

Then nothing will happen because you are calling on a nil object. So your app won't just fall over in a big heap. Or if you then have somewhere else in the code

[myObject release];

Then it will release on a nil object and so won't over-release.

Obviously you should just avoid calling on an object that you have already released!

score 2 · Answer 5 · edited May 23 '17 at 12:10

I would always set to nil.

Apple themselves sometimes (documented) check for nil.

Example;

If you set the navigationItem.titleView needs to be set back to nil if you want to revert back to using navigationItem.title, or your title will not be displayed.

There are lots of references to this "nil checking" in the Apple documentation.

Reference;

https://developer.apple.com/library/ios/#documentation/uikit/reference/UINavigationItem_Class/Reference/UINavigationItem.html

Restoring navigationItem.title after removing navigationItem.titleView

score 1 · Answer 6 · answered Feb 14 '12 at 11:41

not really, but better to use it to prevent errors...

if you call somewhere in your code myObject when it's been release it give you a bad error, but if it's stetted to nil the error may by bypassed

if you try:

myObject.someProperty = 1;

or

if (myObject) {...}

and you just released myObject, it just could crash your app...

score 1 · Answer 7 · answered Feb 14 '12 at 11:42

It is not required, but it is generally considered to be good practice in all environments, with the exception that it is generally considered unnecessary in a -dealloc method.

The reason it is common to set the object pointer to nil after release is because the Objective-C method dispatcher will not try to send a message to a nil object, which means that you're safe to accidentally use the object later.

Boris Vidolov · Answer 8 · 2014-05-07T03:38:27.517

I would suggest a hybrid approach. Let us look at the typical app requirements:

We want to minimize application crashes in production
We want to catch problems like accessing potentially released memory, while we are testing

A good solution is to conditionally assign to:

Nil in release builds
An intentionally bad pointer (e.g. 0x20) in debug.

This brings stability in production builds, but in debug mode any attempt to access the variable will explicitly crash the application. Please note that calling release on an object does not guarantee that the object memory will be deleted hence the need to explicitly set to bad pointer.

#ifdef DEBUG
    #define RELEASE(obj) [(obj) release]; (obj) = (id)0x20;
#else
    #define RELEASE(obj) [(obj) release]; (obj) = nil;
#endif

score 0 · Answer 9 · answered Feb 14 '12 at 11:44

after release an abject but not assign NULL, it keeps the address but content is deallocated. So now it is not pointing to any valid memory location.Hence ptr is now dangling pointer which probably having a address but not pointing to any valid memory location. so it is good practice to assign NULL after freeing the allocated memory as below

ptr=NULL;

in this way dangling problem will be solved.

score -2 · Answer 10 · answered Feb 14 '12 at 11:50

At an Apple Tech Talk I went to a couple of years ago the Apple engineers discussed a few instances where it was essential to assign to nil, but I can't recall the details other than it was inside dealloc in the instances discussed. Suffice it to say that it's not correct to say that you never have to or that it's bad-practice to do so. Sometimes you have to. But most times you don't have to. Sorry my memory isn't clearer.

What is the need of assigning 'nil' after releasing an object

10 Answers10

Linked