Mark D. Gerl asked:
> There's something that's just "uncomfortable" about dereferencing
> pointers without first checking for validity. Is it just me?
I don't think its just you, though most Cocoa types eventually give up
and go with the simpler 'just trust it, it works' approach. Personally,
I think relying on the 'nil eats all messages' is the road to damnation,
but the Cocoa frameworks do it internally so there's no avoiding it, its
never going to change.
(For the record, when I add an IBOutlet to a class definition, I add the
corresponding assertion that its non-nil to the awakeFromNib method
because I *know* that I forget to connect those things up, and have
wasted days chasing unexpected 'nil' objects)
One thing I wonder about in your example, however, is why you don't have
the else cases populated? (I realise it's a coded-in-email example, but
it's the quality of the paranoia I'm interested in) ie, if I'm going
to be so paranoid as to check that the status bar exists, I'm going to
have a strategy for when it isn't. ie,
if (systemBar != NULL)
{
...
} else {
// what would you put in here to let the user know that
the system has
// gone kablooey?
}
My attitude comes down to "unless its going to be a state where the
system is still stable enough to display alert messages, I might as well
just let it dump core - at least that way, I get a stacktrace".
I realise that's a bit radical but I've spent too many years *removing*
badly-formed paranoia from (other peoples) code that did this 'check for
nil' protection but didn't bother propagating the problem out to a layer
that should actually do something about it, instead just returning an
'it worked ok' status.
(Personally, I think this is the only place where throwing exceptions is
truly justified)
But if you aren't going to raise an error somehow, then there's no
reason for not cascading the method calls together. Except perhaps ease
of breakpointing when chasing that elusive failure that "couldn't
possibly" be in the middle of a complex expression...
_______________________________________________
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 arch...@mail-archive.com
