Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?
Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?
- Subject: Re: [super dealloc] when init fails. Was: Logging pointer EXC_BAD_ACCESS?
- From: Quincey Morris <email@hidden>
- Date: Sun, 29 May 2011 13:17:01 -0700
On May 29, 2011, at 12:57, Ken Thomases wrote:
> But it's important to recognize that there are good arguments on both sides and the design decision involved a tradeoff. In any case, it doesn't seem to me that that design decision necessarily implies that calling super with a nil self should also be safe. The two can be considered separately. In this case, it was actually good that it crashed, since Jerry's code had a bug and it was found earlier than it might otherwise have been. Put another way, what nice patterns would be enabled if it were safe to message super when self is nil? In the absence of any, the argument tilts heavily in favor of disallowing it.
I don't disagree with this rationale -- it may be a good idea. But there's a question of what's in the API (or runtime documentation in this case) contract. What I read here:
developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ObjectiveC/Chapters/ocObjectsClasses.html
is this:
> Sending Messages to nil
>
> In Objective-C, it is valid to send a message to nil—it simply has no effect at runtime.
That's pretty unequivocal.
The significance of calling it a bug is that someone might actually file a bug report, which might result in Apple either allowing nil in the super case or changing the documentation to match the actual behavior. I don't care which is the outcome, but I think one of those things should happen.
_______________________________________________
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