On 27-Jun-2011, at 9:22 PM, William Squires wrote:
> The favored form for writing an init method seems to be
>
> -(id)init
> {
> if (self = [super init])
> {
> // Do something here
> }
> return self;
> }
actually I think the current favoured method is
-(id)init
{
self = [ super init ];
if( self )
{
// your code here
}
return self;
};
>
> Several questions arise:
> 1) Isn't the 'if' superfluous? if self was nil (after the assignment from
> [super init]), any messages sent (in the commented section) to it would do
> nothing. The real problem would be if you accessed the instance variables
> directly to initialize them to some non-zero value.
>
And that's usually the case, either you are setting instance variables or
calling some other object methods on other objects, so, no, you usually use the
if() to avoid that code entirely and fast-fail right out of the method.
> 2) Isn't the prevailing paradigm to raise an NSException if something goes
> wrong? In which case, maybe the above code should be more like:
>
> -(id)init
> {
> if (!(self = [super init]))
> {
> // Raise an NSException here
> }
> // Do initializations here
> return self;
> }
>
> or is 'init'ing a special case?
init returning nil on error is the usual paradigm. For instance it's used in
that code above, if( self ), indicates that if the superclass init failed and
it returned nil, so the subclass then returns nil.
>
> What if I have an init method, and - in the above '// Do something here'
> section - my initializations fail (maybe a resource can't be located/loaded)
> - should I raise an NSException, or set self=nil so that any subclasses will
> get a nil when they call my class' init through the [super init] part?
>
return nil would be normal. If the original caller of alloc/init can't continue
without this object, it should raise an exception or attempt some kind of
recovery when it receives nil. It is your application and code however so if
you want to raise an exception in some init case you're welcome to do so, but
that's not particularly usual. Possibly if you had an
initWithParam:param:param: type method and you supplied parameters which were
invalid, you might raise an exception there instead of returning nil.
You should also, in the case you mention, of succeeding [ super init ] and then
failing in the if(), think about dealloc'ing self and setting it to nil, else
you are leaking it. There's been quite a lot of conversation about that in the
past, whether you should call [ super release ] or [ super dealloc ] if your
initialization code fails, I can see it both ways.
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
