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: Graham Cox <email@hidden>
- Date: Fri, 18 Apr 2008 15:16:18 +1000
On 18 Apr 2008, at 3:01 pm, Adam P Jenkins wrote:
I don't understand how the nil-swallows-messages behavior relieves
you of having to check for errors.
I never said it did. But there are plenty situations where getting nil
isn't an error, it's just reflective of a particular state.
The way you've worded the choice, you obviously intended "b" as the
correct answer. However that's based on your assumption that
ignoring an error will only cause a "very minor glitch". It seems
just as likely in general that ignoring an error will cause more
than a minor glitch, in which case the user isn't any better off,
and the programmer who has to fix the problem is worse off since the
problem won't show up until later.
Nothing about Obj-C's convention of swallowing messages to nil means
you don't have to work to write correct code. However knowing that a
message to nil is generally "safe" when writing that code means that
by and large any problems that arise at runtime that you didn't
anticipate at coding time are very often benign. Not always, for sure,
so you still have to test, test, test... but in the odd corner case
you didn't test that a user finds, this approach means you might just
get away with it.
The point of what I was trying to say is that at coding time you can
take advantage of the knowledge that messages to nil are safe to
simplify your code and avoid a lot of redundant checks for pointer
validity. I wouldn't advocate it as an excuse for writing sloppy code.
Here's a simple example:
- (void) dealloc
{
[someIvar release];
[super dealloc];
}
is <someIvar> really initialised? Maybe it's nil? Do I care at this
point? no - either way, the code is correct - if the object was made,
it's released, if it wasn't, it's a no-op. Exactly what you want.
G.
_______________________________________________
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