Initializing NSError **, again Re: CoreData Migration Problems
Initializing NSError **, again Re: CoreData Migration Problems
- Subject: Initializing NSError **, again Re: CoreData Migration Problems
- From: Fritz Anderson <email@hidden>
- Date: Tue, 8 Feb 2011 17:07:00 -0600
On 8 Feb 2011, at 2:51 PM, Quincey Morris wrote:
> P.S. It's OT, but initializing 'error' to nil before passing it to an error-returning method is both a waste of time and semantically incorrect -- it's an *output only* parameter to the method. OTOH, setting it to nil isn't inherently harmful. :)
The documentation for AVAudioPlayer's initWithContentsOfURL:error: and initWithData:error: methods, however, call for "the address of a nil-initialized NSError object," whatever that is. I think they mean a nil-initialized pointer to an NSError pointer. There's similar language for AVAudioRecorder.
I can't imagine this is correct. It is against the semantics for NSError** returns everywhere else in Cocoa. What would the method do with the nil, or with a non-nil value, for that matter? I'd always assumed that the only thing that happens to the input value of *error is that it is blindly overwritten.
But the docs say *error has to be nil, so I'm doing it.
I'm filing a bug against the documentation because it's flat wrong; or if it's right, it's a workaround for a bug, and the variance from universal practice has to be flagged conspicuously, not just casually mentioned.
— F
_______________________________________________
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