Re: -(id)init methods, NSExceptions, and returning nil
Re: -(id)init methods, NSExceptions, and returning nil
- Subject: Re: -(id)init methods, NSExceptions, and returning nil
- From: Roland King <email@hidden>
- Date: Mon, 27 Jun 2011 21:38:14 +0800
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@hidden)
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:
This email sent to email@hidden