Re: Initializing NSError **, again Re: CoreData Migration Problems
Re: Initializing NSError **, again Re: CoreData Migration Problems
- Subject: Re: Initializing NSError **, again Re: CoreData Migration Problems
- From: Greg Parker <email@hidden>
- Date: Wed, 9 Feb 2011 12:46:15 -0800
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 email@hidden Runtime Wrangler
_______________________________________________
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