Re: Checking for NULL (was "Re: Can't get setDelegate to work...")
Re: Checking for NULL (was "Re: Can't get setDelegate to work...")
- Subject: Re: Checking for NULL (was "Re: Can't get setDelegate to work...")
- From: Steven Noyes <email@hidden>
- Date: Thu, 05 Mar 2009 07:32:24 -0600
On Mar 4, 2009, at 7:54 PM, Mark D. Gerl wrote:
Precisely.. code-in-email. I do handle all else cases, and wrap it
all up inside exceptions. Kind of habit by now.
What I was kind of fishing for in the nil/NULL checking - was - to
recognize that it seems Cocoa programmers are trending towards the
lazy side (like Java); and there's too much "just trust the force,
Luke" stuff going on there. Preventative programming seems to go
right out the window, and what makes me think twice about all of
this stuff is this - it's all sitting on top of C; and no amount of
magic will help you track down gnarly memory overwrites and such,
than trying to trap anomalies as soon as you can. The key, though, is
I don't see this as the lazy side as much as the "smart" side. In any
language definition (and all languages are built on top of assembly at
some point) there are specific aspects of the language. In C++,
accessing an object that has a NULL pointer is defined to send you to
the dump. In Objective-C, it is defined as any call to a nil object
is effectively a NOP. It is defined to do nothing. This makes the
following code:
if (someObject != nil)
{
[someObject doSomething:self];
}
The same as:
if (someObject != nil)
{
if (someObject != nil)
{
[someObject doSomething:self];
}
}
From a testing standpoint, the second condition is purely untestable
and includes a dead branch condition. At the end of the day, it
really means you wrote WAY too much code. A second point is, simply
checking for nil is not enough. If you are checking for error
conditions, you must provide an alternate path to do something about
it even if it is to exit. To have a dormant failure in the code is
not a good thing and these can take months to locate. If nil is
possible but undesirable, trap it and take some action.
Steven
_______________________________________________
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