Re: Crash in NSPersistentDocument writeToURL:ofType:forSaveOperation:originalContentsURL:error:
Re: Crash in NSPersistentDocument writeToURL:ofType:forSaveOperation:originalContentsURL:error:
- Subject: Re: Crash in NSPersistentDocument writeToURL:ofType:forSaveOperation:originalContentsURL:error:
- From: Jim Thomason <email@hidden>
- Date: Thu, 27 Jan 2011 07:36:45 -0600
> Well, no. 'error' is an OUTPUT ONLY pointer. Specifically, on entry:
>
> 1. 'error' is either NULL (no error information should be returned), or a valid address to return a NSError* into, if an error occurs
> 2. '*error' is trash (<-- subtle, but important)
>
> On output:
>
> 1. If 'error' was NULL, you of course don't try to return anything
> 2. If 'error' is non-null and you return NO, '*error' must point to a valid NSError object that you created
> 3. If 'error' is non-null and you return YES, '*error' does not need to be preserved (you can set it whatever trash you want) (<-- subtle but important)
>
> If I read your post correctly, you're trying to interpret '*error' as input, which is a no-no.
No, not quite. More accurately I was assuming that error is explicitly
a pointer to nil upon entry (or, I suppose, a pointer to some other
valid NSError that appeared from somewhere and was handed through to
us).
So basically the important thing is that setting error to something
(even a nil, at a minimum) is required if writeToURL:... returns NO.
Which makes sense if the input pointer could be garbage. And
specifically, the fix that I came up with of explicitly setting *error
= nil is the proper fix.
Otherwise, returning NO without explicitly setting the error parameter
will result in a dangling pointer and undefined results.
I still think this is a bad thing. At a minimum, I'd consider it a
documentation bug where the docs need to explicitly state that you
have to assign to it in some manner if you return NO. It's possible
that the docs may say that somewhere regarding object pointers handed
in like this in general, but I sure didn't see it in
NSPersistentDocument's.
I'm not that up on my pointer allocations. Is there some
memory/performance reason why it isn't explicitly set to a nil first?
Personally, if I'm using one of these methods that takes an NSError**,
I always hand in a pointer to an explicit nil to ensure the space is
wiped clean.
Incidentally, it originally manifested for me because I have some
fancy code to combined complex errors into a single message for
display purposes so as not to display a "Multiple Validation Errors
Ocurred" message. That code was what was assuming that it'd be given
either a valid NSError or nil, because it's called very recursively
internally elsewhere in the code.
Thanks for the info this makes it much more clear.
-Jim.....
_______________________________________________
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