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: Wim Lewis <email@hidden>
- Date: Wed, 9 Feb 2011 14:02:11 -0800
On 9 Feb 2011, at 11:04 AM, Scott Anguish wrote:
> If you pass &blah, if there is no error, blah == nil
>
> Perhaps by-reference would be a better terminology.
>
> Returns, by-reference, an NSError object if the regex is invalid; otherwise nil. Pass nil if you don't care.
My understanding is that the canonical pattern is:
1. If the method fails, it will return an (autoreleased) NSError object in *error.
2. Method failure is indicated by its return value, not by anything involving the error parameter.
3. If the method succeeds, it will not modify *error.
4. In no case will the method read or depend on the initial value of *error.
5. error may safely be NULL.
Your description differs with mine on point 3. OTOH, the documentation weakly implies point 3, and point 3 does describe the *actual* behavior of methods like -[NSData initWithContentsOfFile:...].
Points 3, 4, and 5 are often not explicitly documented, and in some cases the documentation contradicts them, e.g. the AVAudio* classes as Fritz Anderson points out. (The documentation also regularly confuses nil, NULL, and NIL.)
Apple's code has not always agreed with point 5, though I think those have been fixed in more recent releases.
IIRC, some Foundation methods are documented to differ on point 2, but I don't trust the documentation to be correct on that.
Some of Omni's frameworks differ on point 4 (there are methods for which if *error is non-nil it will be stored in the returned error under NSUnderlyingErrorKey) but I'm not convinced this is useful/desirable behavior.
Really the only point I can rely on is point 1. Ben Trumbull's advice helps to write code that behaves correctly even when calling code that doesn't quite conform to the above pattern (including, as Greg Parker notes, messaging nil--- I hadn't thought of that case...).
_______________________________________________
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