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 (Cocoa-dev@lists.apple.com) 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/archive%40mail-archive.com This email sent to arch...@mail-archive.com
