Re: When init returns nil does it cause a leak
Re: When init returns nil does it cause a leak
- Subject: Re: When init returns nil does it cause a leak
- From: Quincey Morris <email@hidden>
- Date: Tue, 19 May 2009 10:58:06 -0700
On May 19, 2009, at 09:32, Jesper Storm Bache wrote:
I personally disagree with the Apple recommendation, and I vote for
calling [super dealloc] when initialization fails - because this
will invoke dealloc only in the base classes where init succeeded.
First of all, in general, it can't work. If it were permissible to
write '[super dealloc]' anywhere other than in a dealloc method, you'd
have to be certain that there were no outstanding extra retains on the
object, and you can't know that. One of the "base" inits might have
done something that resulted in a retain/autorelease on the object,
for example.
Second, in general, when an init method decides to fail, its object is
already partially initialized. So in addition to (hypothetically)
calling '[super dealloc]', it would also have to back out some
initializations, and it comes down to a choice between (a) adding code
to init to back out the initializations or (b) adding code to dealloc
to avoid doing anything dangerous on a partially-initialized object.
The problem with (a) is that it will duplicate -- multiple times if
there are multiple errors to detect -- some code that's already in
dealloc. The advantage of (b) is that it centralizes the knowledge of
how to handle un-initialization in dealloc. (In most cases, the only
backing out that needs to be done is releasing instance variables. As
far as that's concerned, [self dealloc] is safe without special-casing
anything.)
_______________________________________________
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