On Jan 29, 2013, at 10:51 PM, Ken Thomases <[email protected]> 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 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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
