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: Clark Cox <email@hidden>
- Date: Thu, 5 Mar 2009 10:07:28 -0800
On Thu, Mar 5, 2009 at 5:32 AM, Steven Noyes <email@hidden> 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.
It's actually worse than that. It's not defined as doing anything at
all. So it's perfectly possible, in C++, for it to "work" for years,
and only fail when the stars align.
--
Clark S. Cox III
email@hidden
_______________________________________________
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