On Feb 9, 2011, at 12:46, Greg Parker wrote:
> 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
On Feb 9, 2011, at 2:02 PM, Wim Lewis wrote:
> 3. If the method succeeds, it will not modify *error.
This is incorrect, I think. If the method succeeds, then *error may or may not
have been modified.
> (The documentation also regularly confuses nil, NULL, and NIL.)
nil and Nil and NULL are pr
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 i
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. Wri
On Feb 9, 2011, at 11:19 AM, Bill Bumgarner wrote:
>
> On Feb 9, 2011, at 10:51 AM, Matt Neuburg wrote:
>
>>> error
>>> An out value that returns any error encountered during initialization.
>>> Returns nil if the regular expression pattern is invalid.
>>
>> Really? :) m.
>
> I read that as
, at 1:51 PM, Matt Neuburg wrote:
>
>> Date: Tue, 8 Feb 2011 17:07:00 -0600
>> From: Fritz Anderson
>> Subject: Initializing NSError **, again Re: CoreData Migration
>>Problems
>>
>> I'm filing a bug against the documentation because it's fla
> Date: Tue, 8 Feb 2011 17:07:00 -0600
> From: Fritz Anderson
> Subject: Initializing NSError **, again Re: CoreData Migration
> Problems
>
> I'm filing a bug against the documentation because it's flat wrong; or if
> it's right, it's a wo
On Feb 9, 2011, at 09:09, Matt Neuburg wrote:
> From Bill Bumgarner:
>
>
>> If the method fails -- if file is nil -- the 'error' will be filled in
>> with an [autoreleased] NSError instance describing the error.
>> However, 'enc' will be undefined.
>>
>> If the method succeeds, file and e
On Tue, 8 Feb 2011 17:07:00 -0600, Fritz Anderson
said:
>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
On Feb 8, 2011, at 15:07, Fritz Anderson wrote:
> 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 NS
On 8 Feb 2011, at 5:07 PM, Fritz Anderson wrote:
> 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 N
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 har
12 matches
Mail list logo
