CODEWITHSUNDEEP
iphoneiosobjective-cios6
Kondamoori
Kondamoori

Reputation: 33

Can we check if the object is nil or not, before going to release in dealloc method of a class

Can we check the object is nil or not before going to release in dealloc method. I am new to objective C. Is this right way to avoid segmentation issues?.

-(void)dealloc{
  if(stringObject!=nil){
   [stringObject release];
   }
 }

Upvotes: 1

Views: 1128

Answers (4)

Rob van der Veer
Rob van der Veer

Reputation: 1148

A simple 

if(stringObject)

will do, if you just want to check if the variable points to an object.

But with Objective C it is not necessary to test for nil because an message to a null object will simply do nothing. So it is enough to say:

-(void)dealloc
{
    [stringObject release];
    stringObject = nil;
    [super dealloc]; //added because of the comments
}

Under ARC, you can leave out the whole dealloc in most situations, because 1) the release is managed automatically, and 2) the call to dealloc is the made just before the object ends it's life, so the nil is not necessary. However, if you use custom c-style allocation you may still need an alloc method. But this belongs to an advanced topic.

Here's a link to the dev guide on working with objects in general:

https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/WorkingwithObjects/WorkingwithObjects.html#//apple_ref/doc/uid/TP40011210-CH4-SW1

Upvotes: 1

ludesign
ludesign

Reputation: 1373

Yes you can. Before ARC there was a very common macro defined

#define SAFE_RELEASE(object) if (object != nil) { [object release]; object = nil; }

  • NOTE: However, sending a message to nil will return nil.

Upvotes: -1

fzwo
fzwo

Reputation: 9902

This suffices as a nil test (your way is also correct, just slightly longer):

if (stringObject)
{
    //do something
}

But in a simple case like yours, you don't even have to do that, because in Objective-C, sending messages to nil objects just means nothing happens:

[aNilObject doSomething]; //nothing happens, this is perfectly valid and won't throw an exception; it won't even log anything. Once you're used to it, it's great and avoids lots of boilerplate nil checks.

Going further, in your case, you should switch to ARC (after you're done learning manual retain and release, which is a good exercise).

Your code would then look like this:

//you don't need to call dealloc at all in ARC :)

Upvotes: 0

sergio
sergio

Reputation: 69027

Testing for nil before release is fully redundant in Objective C and will not add any resiliency to your code.

Indeed, the whole point of segmentation faults (EXC_BAD_ACCESS) is having a pointer which is not nil, thus points to some memory, and accessing that piece of memory after it has been freed.

If the pointer is nil in the first place you will not be possibly able to access any memory with it and you will not have a segmentation fault in Objective C (unlike C or C++).

The real solution to segmentation faults is correct memory management. If retain/release management seems too complex, you can have a look at ARC, which has its own intricacies, though (although much less than manual retain/release management).

Upvotes: 4

Related Questions