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 01:01:03 -0400
On Apr 17, 2008, at 9:19 PM, Graham Cox wrote:
On 18 Apr 2008, at 8:42 am, Adam P Jenkins wrote:
trying to invoke a method on whatever their equivalent of nil is
produces a runtime error of some sort.
Actually in C++ it produces a solid, good old fashioned crash (I
don't know about the others).
I will agree that getting a segfault in C++ isn't desirable to a
user. I was more thinking of ObjC's behavior relative to other higher
level languages like Java, Python, Ruby, or Smalltalk. In all of
these, a NullPointerException need not cause the application to exit
if you don't want it to. Typically applications have a catch block at
the top level of the application which handles exceptions which make
it up to there by logging them and/or displaying them to the user, and
at least offering the user the choice of continuing if they want to.
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.
I don't understand how the nil-swallows-messages behavior relieves you
of having to check for errors. Maybe in throw-away code, but in any
production code I wouldn't want to just ignore errors and hope the nil-
swallows-messages behavior keeps the errors from being serious.
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.
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.
Anyways, I don't mean to start a flame war or anything. I'm a
programming language geek, and just like to learn about different
languages' designs, and the idioms that arise as a result. I haven't
seen this behavior of nil in any other language, so I'm just trying to
understand how it's useful.
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