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 (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
