Re: verify input parameter of init method and return nil before invoke [super init]
Re: verify input parameter of init method and return nil before invoke [super init]
- Subject: Re: verify input parameter of init method and return nil before invoke [super init]
- From: Charles Srstka <email@hidden>
- Date: Tue, 29 Jan 2013 23:43:21 -0600
On Jan 29, 2013, at 10:51 PM, Ken Thomases <email@hidden> wrote:
> I disagree. I think Bob's construction is valid, if unconventional. It is also valid-though-unconventional to release an object that you've +alloc'd but not -init'd at the caller side.
>
> SomeClass* foo = [SomeClass alloc];
> if (someCondition)
> {
> [foo release];
> return;
> }
> foo = [foo init];
>
> Bob's construction is just as valid as the above because it's essentially doing the same thing.
>
> You're right to argue that, in practical terms, some classes may have -dealloc implementations that fail in these circumstances, but then those -dealloc implementations are buggy.
While that may be true, those dealloc methods, which you may not have control over, are still going to be there, and can potentially be a problem. Heck, without access to the source code, we can't even be sure that the framework classes won't have this problem. Releasing an object without init'ing it first is unusual enough that it's not inconceivable that people could fail to be aware of this possibility.
This is especially true for classes that use KVC, since there's no obvious way to ask the system whether you're already registered as an observer for something or not (other than setting a flag in your object when you add the observer), and -removeObserver:forKeyPath:context: will throw an exception if you call it when you're not already an observer.
It may look ugly, but I'd still call [super init] before releasing self, just for safety's sake.
Charles
_______________________________________________
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