On Oct 2, 2009, at 7:45 AM, Bill Bumgarner wrote:
In either case, assuming the undefined reference is nil would be a
bug. Initializing the variables to nil prior to the call isn't going
to change anything in that regard.
(And, yes, there are methods that modify their error parameter on
success -- purely an implementation detail. Perfect valid thing to
do since the return value is undefined on success.)
Ouch. So the following pattern is incorrect?
NSError* internalError = nil;
(void)[foo somethingReturningBool:bar error:&internalError];
if (internalError) {
// ...
}
I got into this habit because most every method is documented to say
things like "parameter used if an error occurs" and "May be NULL".
You're saying that some methods go out of their way to trample my
(potentially unavailable) error storage even on success? I'm starting
to worry that I'll spend tomorrow fixing much old code instead of
getting to make new mistakes...
thanks,
-natevw
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
