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 PROTECTED]> 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 (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 [EMAIL PROTECTED]
