Re: I want my app to crash!
Re: I want my app to crash!
- Subject: Re: I want my app to crash!
- From: Andreas Grosam <email@hidden>
- Date: Wed, 17 Jun 2009 10:33:25 +0200
On Jun 17, 2009, at 3:27 AM, Jim Correia wrote:
On Jun 16, 2009, at 6:58 PM, Andreas Grosam wrote:
On Jun 16, 2009, at 11:33 PM, Jim Correia wrote:
Another example is chained message sends where an inner message
send may return nil.
MyClass *obj = [[MyClass alloc] init];
You can do this, if you program is error-agnostic - or handles nil
objects in some seamless fashion so that the existence of nil
objects is the normal case. In fact, I think this is possible,
however only in a very limited scope.
Otherwise, you simply ignore the fact that there might be an error
either intentionally or unknowingly.
Unfortunately, I failed so far to accomplish to create a program
that is nil-object-agnostic across the whole code - I fear this is
impossible for a reasonable complex program. So, honestly, it's far
*easier* to ensure eventually that an object is not nil, or have
otherwise ensured that your program never takes the error path,
that is, getting nil objects somewhere. Dealing with objects that
might validly be nil, can quickly become a pita.
I'm not suggesting you write code that is nil object agnostic across
the entire code base.
But it stands that a common Cocoa idiom is to write
MyClass *obj = [[MyClass alloc] init];
If messaging nil were suddenly a hard runtime error, millions of
lines of code which look just like that would be problematic.
They potentially are - no matter if the runtime allows sending to nil
receivers without issuing diagnostic messages or not.
This statement is only not problematic when
a) you ensure your init method will always return a valid object or
otherwise throw an exception or terminate the program.
b) your init routine cleans up properly on an error and returns nil,
AND the client code can handle nil objects properly.
Valid code which reads
if ([string length] > 0) { do something }
When reading this code, it implies to me that string may NOT be
validly nil - AND it has been ensured that string is never nil at
this moment.
I think, it is in no way clear for the reader of the code, that this
statement is also valid for nil receivers. Please, if this is
intentionally the case, add a comment or write it explicit.
would have to be replaced with the slightly more verbose
if (string != nil && [string length] > 0) { do something }
This code implies to me that string may be validly nil - that is, it
is no error when string equals nil.
If you have to write this instead of the above code, you have a
(potentially) bug in your code above - or at least it's a dangerous
programming style.
The last code statement is also incorrect if you want to check for
errors where string equals nil:
Instead you have to write:
NSAssert(string);
if ([string length)] > 0) { ... }
or alternatively:
if (string != nil) {
do something
}
else {
handle the error
}
For all practical purposes this ship has sailed. Sending a msg to
nil is valid in Obj-C. Rather than wishing it were not :-),
The runtime allows receivers to be nil- and it may be "valid Obj-C".
But if such a statement is valid according your program logic is
totally different ;)
When the runtime silently accepts nil receivers it does not mean that
your code is correct.
Having examined your example and having said this, it should become
clear that it would be very helpful when the runtime would send
diagnostic messages when a receiver is nil - at least if there were a
environment variable which could control it.
I cannot see from your examples above that there is any fact that
supports your statement: "Sending a msg to nil is valid in Obj-C.
Rather than wishing it were not " ;)
it is more productive to discuss strategies for finding bugs where
nil is an unintentional receiver.
True. And my suggestion was to add NSAssert or if (..) where
appropriate. Preferable testing the code extensively with unit tests.
Once after you suspect the horse has already left the barn, you may
consult dtrace or follow the excellent suggestions from BB.
However, I would prefer the runtime would optionally send a diagnostic
message - and let *me* decide whether this is an error or not in my
program. This would be the most effective strategy.
Regards
Andreas
_______________________________________________
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