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: Roland King <email@hidden>
- Date: Thu, 05 Mar 2009 21:53:26 +0800
On Mar 5, 2009, at 9:32 PM, Steven Noyes wrote:
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
One small point .. sending a message to nil is defined to do nothing
at runtime, do however read the actual documentation which describes
what is returned in the case that the method returns something. Thus
far for me the default return has made sense, but if you're sending
messages to nil and they have return values, you have to consider if
having a default return (for instance returning 0) gives you the
information you need or if you do need to check for nil in those cases
in order not to get a bogus value you then use.
_______________________________________________
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