Re: Why is [nil aMessage] a no-op?
Re: Why is [nil aMessage] a no-op?
- Subject: Re: Why is [nil aMessage] a no-op?
- From: Jeff <email@hidden>
- Date: Thu, 17 Apr 2008 18:46:28 -0600
I find it very useful, since messages to nil are valid, a whole lot of
exception handling can be avoided (since it's done for you). Generating a
run-time error would imply that you shouldn't send a message to nil, which
would mean that you ought to do nil checks each time you change/set a
pointer.
A compile option to generate run time errors for messages to nil could be
useful for debugging.
On Thu, Apr 17, 2008 at 4:42 PM, Adam P Jenkins <email@hidden> wrote:
> I'm curious if anyone knows the rationale behind the decision to make
> sending messages to nil be a no-op in ObjC. I've used a number of other OO
> languages, including C++, Java, Python, Ruby, Smalltalk, and Javascript, and
> in all of them, trying to invoke a method on whatever their equivalent of
> nil is produces a runtime error of some sort. In practice, I've found
> Obj-C's practice of ignoring method calls to nil to be just annoying, since
> it masks bugs unless you turn on NSZombiesEnabled. I can imagine that
> sometimes it would be convenient to have some kind of message sink which
> just accepts and ignores all messages, but why not just have a special
> NSSink class for that instead of making nil behave that way?
>
> I know there's no chance of this feature of the language changing at this
> point. I'm just wondering if there's some good rationale for it that I'm
> not thinking of. Thanks,
>
> Adam
> _____________
_______________________________________________
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