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: Adam P Jenkins <email@hidden>
- Date: Fri, 18 Apr 2008 00:20:06 -0400
On Apr 17, 2008, at 7:07 PM, Bill Bumgarner wrote:
(1) And many Java programmers find the constant need to check for
nulls or null pointer exceptions to be ugly and inconvenient....
I would agree that this was a problem if I thought it was common to
encounter situations where invoking methods on a null object wasn't
just a mistake. In fact though it's almost always a mistake, for
instance because you left out an error check, so it's actually
convenient that in Java you deterministically get a
NullPointerException along with a nice stack trace showing exactly
where it happened. Besides Java APIs typically throw exceptions to
indicate errors rather than returning null, so I don't find that
there's any constant need to check for nulls in Java code anyway.
This is much more of an issue in ObjC or C++, because ObjC and C++
APIs use nil/NULL return values to indicate errors much more often
than Java.
(3) Some history:
When NeXTSTEP was originally designed (mid '80s), the APIs generally
followed a pattern of always returning self. That is, instead of:
- (void)setFrameOrigin:(NSPoint)newOrigin;
- (void)setFrameRotation:(float)angle;
- (void)removeAllObjects;
- (void)setArray:(NSArray *)otherArray;
It would follow this pattern:
- setFrameOrigin:(NSPoint)newOrigin;
- setFrameRotation:(float)angle;
- removeAllObjects;
- setArray:(NSArray *)otherArray;
And, thus, you would commonly see code in chained form:
[[[aView setFrameOrigin: p] setFrameRotation: 42.0] setNeedsDisplay:
YES];
Or, in some cases, even longer. Now, if a 'nil' were produced by
any of the sub-expressions, not having nil-eats-message behavior
would mean that an exception would be raised in a spot where there
was no convenient means of figuring out what is going on. Not
having nil-eats-message meant that such chains could be written
without worry.
Thanks a lot for the explanation. The feature makes more sense to me
now.
Smalltalk has the same convention of returning self from methods so
that methods can be chained. (I'm guessing it's no coincidence that
ObjC adopted the same convention initially.) However Smalltalk
doesn't have the nil-eats-message behavior. I'd guess this is because
in Smalltalk, errors are more likely to be indicated by throwing an
exception rather than returning nil, so if an error occurred in the
middle of a chain like the above, then the execution of the chain
would be aborted by the exception rather than causing a
NullPointerException later in the chain.
Of course (and as you have discovered), there are an awful lot of
situations where a 'nil' return value is actually indicative of a
serious problem -- something has failed that shouldn't have. And
tracking it down can be a pain.
Exactly. And now that the convention of methods returning self no
longer exists, it seems like there's no longer any advantage to this
behavior.
Thanks for the explanation and history lesson,
Adam
_______________________________________________
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