What is the point of implementing Objective C init methods like this?

Question

Possible Duplicate:
In Objective-C why should I check if self = [super init] is not nil?

I often see this "if (self = [super init])" construct and I wonder why it's done.

- (id) init {

  if (self = [super init]) {

    // how could self = [super init]; ever fail?

  }

  return self;

}

Answer 1

Imagine your superclass does this:

- (id)init {
    self = [super init];

    if (self) {
        self->foo = CreateExpensiveWidgetOverTheInternetByTrain();
        if (!self->foo) {
            // widget creation failed, bail out
            [self release];
            self = nil;
        }
    }

    return self;
}

That's how. ;)

Answer 2

There are a number of ways [super init] could fail:

1. You are attempting to subclass a "final" class, i.e. one that has been specifically designed not to allow subclassing.

2. You are out of memory, and out of luck.

3. In the case of initWithArgument:parameter:; you have supplied invalid arguments or parameters.

Also, other less obvious ways; which are usually the most dangerous ones.

Answer 3

From the documentation:

In general, if there is a problem during an initialization method, you should call the release method on self and return nil.

There are two main consequences of this policy:

• Any object (whether your own class, a subclass, or an external caller) that receives nil from an initializer method should be able to deal with it. In the unlikely case that the caller has established any external references to the object before the call, you must undo any connections.
• You must make sure that dealloc methods are safe in the presence of partially initialized objects.