Re: Cocoa and messages to nil, revisited
Re: Cocoa and messages to nil, revisited
- Subject: Re: Cocoa and messages to nil, revisited
- From: "Raphael Sebbe" <email@hidden>
- Date: Wed, 8 Aug 2007 09:24:07 +0200
Hi,
passing nil arguments may be completely valid, depending on your methods.
I would recommend using assertion macros in debug mode if you have
specific constraints for your method arguments.
One thing to be aware of though is when a structure is returned by a
method (nil should be tested).
Raphael
On 8/8/07, Jeff Laing <email@hidden> wrote:
> > Doesn't matter. Sending messages to nil is easier to read and well
> > established as generally safe in Cocoa. The areas where it is unsafe
> > are well documented. I enjoy sending messages to nil. Obviously so
> > does much of Apple, and I'm sure much of the rest of the Cocoa
> > developer world.
>
> No argument that
>
> [something release];
>
> might seem easier to read than
>
> if (something) [something release];
>
> but thats the trivial case. This thread started from a discussion of
>
> [something with:[somethingelse using:[thirdthing blah]]];
>
> where somethingelse was *accidentally* nil. The point being that it becomes
> a nightmare to try to FIND that sort of problem since Cocoa gives you no
> help at all, despite Objective-C actually having a hook that *could* help if
> Cocoa were a bit tidier.
>
> The problem here is not that sending message to nil is unsafe. Its that in
> buggy code, sending message to nil is *not what you thought you were doing*,
> and the mechanism that Objective-C provides to catch it is deliberately
> obfuscated by Cocoa design tendencies, which are (in my opinion) lazy.
>
> C++ has the same lazy notion, in exactly one case. "delete NULL;" will
> silently work. ANSI C has the same. "free(NULL)" will silently work. In no
> other case will a nil-pointer-dereference work because in no other case
> should a programmer being doing such a thing. And I contend that in Cocoa,
> the only similiarity is release. I don't care if I send release to nil, but
> I would really like to know why NSMenu sends it copyWithZone: (for example),
> not to mention why Cocoa keeps sending it isKindOfClass:
>
> I don't want to discuss this in terms of language. Its not an Objective-C
> issue, its a Cocoa issue, a style problem. In fact, I don't really want to
> discuss it at all because very few people will consider it objectively
> (sic). I *know* where I have had problems developing with the Cocoa
> frameworks, and a large number of those problems were because message to nil
> could not be detected without tedious "debug-by-printf" insertion of NSLog()
> statements, which is ludicrous. All for the benefit of the lazy programmer
> who didn't want to put 'if(ptr)' in front of messages to objects that might
> not be there.
> _______________________________________________
>
> 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
>
_______________________________________________
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