Re: Best practice for overridden initializers in subclasses

FROM : Andy Lee
DATE : Wed Mar 26 00:26:52 2008

A similar question was asked recently.  To paraphrase (and slightly 
correct) my reply:

I do essentially this:

- (id)init
{
    NSLog(@"%@ -- '%@' is not the designated initializer",
          [self class],
          NSStringFromSelector(_cmd));
    [self release];
    return nil;
}

You can imagine wrapping the three statements in a macro, and/or 
throwing an exception or putting in a breakpoint.

Since there's no way to enforce designated initializers at compile 
time, and there may be no way for you to recover gracefully at 
runtime, the best you can do is catch the error wherever possible 
during development and testing.

--Andy


On Mar 25, 2008, at 6:01 PM, Andy Klepack wrote:

> I have a subclass of NSObject that provides its own designated 
> initializer that allows client code to configure an instance with 
> initial values. Instances of the class itself are immutable. At the 
> same time, instances where no initial values are supplied do not 
> make conceptual sense.
>
> I'm wondering how to deal with overriding the 'init' method of 
> NSObject. There's really no sensible default values that I could 
> have init pass along to my designated initializer. It doesn't make 
> sense for clients to call 'init' and I'm debating whether to return 
> nil, throw some sort of exception, make the instance 'dead' and 
> essentially do nothing, or to do something else..
>
> Anyone have a recommendation for the best practice in this case?
> -Andy
>
> _______________________________________________
>
> Cocoa-dev mailing list (<email_removed>)
>
> 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/<email_removed>
>
> This email sent to <email_removed>