RE: Cocoa and messages to nil, revisited
RE: Cocoa and messages to nil, revisited
- Subject: RE: Cocoa and messages to nil, revisited
- From: Jeff Laing <email@hidden>
- Date: Thu, 9 Aug 2007 08:37:16 +1000
> passing nil arguments may be completely valid, depending on
> your methods.
Oh ye gods and little fish, did I say nil arguments were invalid?
Its nil *receivers* that are the problem I'm trying to catch.
Sorry about that but sometimes it seems like everyone deliberately tries to
miss the point - I wonder some times how people manage to actually write
complicated code...
> > but thats the trivial case. This thread started from a discussion of
> >
> > [something with:[somethingelse using:[thirdthing blah]]];
It's "something"s problem to deal with the with: argument being nil. No
discussion required. Inside the with: method I put an assert that see's the
nil and traps.
I think ... hmmm, thats odd, why would a somethingelse have returned a nil
from its using: call and spend the next hour pursuing that, only to later
discover that the variable 'somethingelse' was nil because I had dropped a
connection in Interface Builder. Or because I'd passed the wrong key to a
dictionary method somewhere whose only error reporting strategy is returning
nil.
Writing robust code is not compatible with writing insanely long chains of
[this uses:[that which:[calls this:[who needs:theother]]]];
and yet thats *exactly* what you see being used in all the samples. I have
exactly *zero* confidence that the authors of that code have really
considered that 'this', 'that', 'calls' and 'who' may well be nil through
some *unexpected* bug.
(Apple pretty much always preface all their sample code with 'error checking
has been left out for clarity)
The truly paranoid would do something like:
id cantbenull(id in)
{
if (in == nil) @throw blah blah...
}
[cantbenull(this) uses:[(cantbenull(that) which:...
you get the picture. Clearly thats a ludicrous style, but I can guarantee
its *never* surprised by nil objects.
_______________________________________________
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