Re: Cocoa and messages to nil, revisited
Re: Cocoa and messages to nil, revisited
- Subject: Re: Cocoa and messages to nil, revisited
- From: Alastair Houghton <email@hidden>
- Date: Thu, 9 Aug 2007 09:24:07 +0100
On 8 Aug 2007, at 23:37, Jeff Laing wrote:
but thats the trivial case. This thread started from a discussion of
[something with:[somethingelse using:[thirdthing blah]]];
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.
IB does warn you if you have missing connections. Sadly it's less
useful than it could be in many cases because sometimes connections
really are optional (and AFAIK there's no way to tell IB that, let
alone to express things like "you must connect one of these five
outlets"), but it is there. Otherwise, if you find odd behaviour
relating to something wired up in IB, the first thing to check
(because it's easy, and a fairly common mistake) is that you've
actually connected it.
Another thing you can do, which will help *enormously* with this, is
to stick NSAssert() calls into your -awakeFromNib methods to check
that you have all the connections you're expecting. You might also
consider checking e.g. data sources and delegates at that point to
make sure they have all the non-optional methods (you can, of course,
use a formal protocol to help with that).
Or because I'd passed the wrong key to a dictionary method
somewhere whose only error reporting strategy is returning nil.
Which you can easily avoid in most cases by declaring constants for
your dictionary keys. i.e. rather than
[dictionary objectForKey:@"Antidisestablsihmentarianism"];
which is going to return nil (there's a mistake there, it's
deliberate...), you should be writing
// As a global
NSString * const kAntidisestablishmentarianism =
@"kAntidisestablishmentarianism";
// In your code
[dictionary objectForKey:kAntidisestablishmentarianism];
If you then make the same typo as in the first instance, you'll find
that the compiler will tell you; moreover, the value of the string
constant doesn't really matter, as long as it's unique for your
dictionary... personally I tend to put the name of the constant in
there, because then NSLog()ing the dictionary will display results
that make sense to anyone looking at the code.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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