Re: looks like Intel vs. PowerPC difference

FROM : Bill Bumgarner
DATE : Thu Aug 03 22:49:50 2006

On Aug 3, 2006, at 11:53 AM, Matt Neuburg wrote:

> I have to say that I agree with Sherm on this. It isn't just this 
> call. I
> have recently rewritten ALL my code where there is a double-pointer 
> like
> this whose value I am going to check afterwards, and guess what - 
> when I
> supply a known value (e.g. nil) at the outset, a bunch of mysterious
> misbehaviours went away. Example:
>
>    NSError* err = nil; // <--- LOOK!
>    NSXMLDocument *xmlDoc = [[NSXMLDocument alloc]
>      initWithContentsOfURL:url options:0 error:&err];
>    [xmlDoc autorelease];
>    if (err) // etc.


Nope -- there are no mysteries here.  The above is incorrect.

You should not *ever* be poking at (err) unless xmlDoc is nil.  That 
xmlDoc is nil indicates that err was set to an error.

The NSXMLDocument class is free to do whatever it wants to err, 
including setting it to a completely bogus state, if the xmlDoc was 
correctly parsed and produced.  It might be that the xmlDoc sets the 
reference pointed to by &err to an allocated instance of NSError that 
is -release'd upon successful completion, but the reference is not 
"cleared" because there is no reason to do so.

Same thing goes for various Core Data and other AppKit methods that 
take an (NSError **) argument.

b.bum