Re: Why is [nil aMessage] a no-op?
Re: Why is [nil aMessage] a no-op?
- Subject: Re: Why is [nil aMessage] a no-op?
- From: "David Wilson" <email@hidden>
- Date: Thu, 17 Apr 2008 21:51:52 -0400
On Thu, Apr 17, 2008 at 9:19 PM, Graham Cox <email@hidden> wrote:
> Actually in C++ it produces a solid, good old fashioned crash (I don't know
> about the others).
>
> This isn't good - it means you have to check every single return value and
> pointer for nil before you can use it - code ends up littered with thousands
> of such checks which mostly don't contribute anything to the code except
> stopping it falling off the rails in unusual circumstances.
>
> Tracking down bugs when a message to nil is simply swallowed is sometimes a
> pain, but I much prefer it to a) having to add all these mostly redundant
> checks, and b) having my program crash hard if I overlooked something (best
> will in the world and all that), instead of just carrying on probably with
> some very minor glitch. As an end user, what would you prefer? Remember the
> bad old days when Mac OS 7, 8 or 9 (or Windows 3, 95, 98 come to that) would
> be crashing all the time for the most minor transgression? - end users hate
> that. Programmers might prefer to be alerted to such problems by a crash,
> but computers aren't in fact FOR programmers, they are for users to do
> things with.
>
> Opinions will vary however ;-)
While I agree in large part as far as end user preferences are
concerned, I think the biggest risk of undetected errors is that of a
program arriving at an invalid state, such that the program's reaction
to subsequent use is not what the user intends or expects- data
corruption or the like. In cases like this, even the end user would
prefer that the program simply halt rather than doing something
actively *wrong*.
I think the question that arises, and a primary reason for preferring
one over the other, is how much of a risk one thinks that scenario is.
Personally, I prefer (even as an end user) that the program simply die
and have done with it rather than having more insidious faults that
may not be initially visible.
--
- David T. Wilson
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