On Feb 9, 2011, at 10:34 AM, Quincey Morris wrote:
> The real world cost in all of this is that it's easy for a developer to
> misunderstand the 'error:' parameter mechanism, in such a way as to code an
> error handling scheme that depends on initialization to a nil value to work
> properly. Writing examples that include the nil initialization just seem to
> me to promote the misconception (and that's a moral position on my part).
Initializing the error to nil is helpful to protect against one nasty hole in
the pattern. Consider this code:
NSError *error;
id result = [receiver doSomethingWithError:&error];
if (!result) NSLog(@"error %@", error);
On failure, -doSomethingWithError: returns nil and sets error. But if receiver
is nil, -doSomethingWithError: returns nil and does not set error. In that
case, the error-handling code may crash after using the uninitialized error
value. If you set error=nil in advance, you can do something correct when
receiver is nil.
--
Greg Parker gpar...@apple.com Runtime Wrangler
_______________________________________________
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
