Re: I want my app to crash!
Re: I want my app to crash!
- Subject: Re: I want my app to crash!
- From: M Pulis <email@hidden>
- Date: Wed, 17 Jun 2009 03:29:13 -0700
On Jun 17, 2009, at 1:33 AM, Andreas Grosam wrote:
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.
I'm with AG on this... I would add:
Most of us see the alloc init pattern when learning from example code
for a quick feature demo. For purposes of brevity, example code is
never meant to demonstrate error handling, much like I don't expect
to see MyClass in shipping source.
There is no shame in writing verbose, defensive code, simply long
term stability when insulated from lower level implementation
details. Particularly in resource limited environments like iPhone.
Just don't program like an idiom. :-)
MP
_______________________________________________
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