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: Ken Thomases <email@hidden>
- Date: Sun, 29 May 2011 14:57:00 -0500
On May 29, 2011, at 2:43 PM, Quincey Morris wrote:
> The difference in the second case is that the compiler translates it (AFAIK) into a call to objc_msgSendSuper instead of objc_msgSend. What I'm winding up to here is that the failure in messaging a nil 'super' looks to me like a bug in the ObjC runtime's implementation of objc_msgSendSuper.
I wouldn't call it a bug in the Objective-C runtime. Assuming that self is not nil in a call to super is a perfectly reasonable assumption -- consider how infrequently it has ever tripped anybody up -- and probably enables some nice optimizations.
The whole issue of "messaging nil does nothing but (usually) return zero" is somewhat controversial because it can hide bugs. I don't have a big problem with it (and quite like the patterns that it enables). 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.
Regards,
Ken
_______________________________________________
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