Re: False positive on writeToURL:atomically:encoding:error: ?
Re: False positive on writeToURL:atomically:encoding:error: ?
- Subject: Re: False positive on writeToURL:atomically:encoding:error: ?
- From: Martin Hewitson <email@hidden>
- Date: Sun, 24 Jun 2012 07:35:38 +0200
Just a quick follow up on this.
It's been stated that it's unsafe to check the error returned from -writeToURL:atomically:encoding:error: and rather one should check the return value. Is this a general statement for other methods which fill an error object on error? For example, what about NSFileManager's -attributesOfItemAtPath:error: ? The documentation makes no statement about the return value in the case of error. Is it standard that the return value will be nil? Or should I check the error object in this case?
This thread triggered me to check through the whole project for places where I check for non-nil error objects. There are a number, so I'd like to ensure I'm doing the right thing in each case.
Any insight gratefully received.
Martin
On 23, Jun, 2012, at 07:59 PM, Eeyore wrote:
> In general, it is not safe to assume that errors from Cocoa frameworks are cleared when an operation succeeds (in fact, I believe that they they are almost never cleared). The only way to determine if "writeToURL" succeeds is to test the return value (not the error). If the return value is YES, the error is garbage. If the return value is NO, the error will have meaning.
>
> NSError *error = nil;
> BOOL success = [content writeToURL:aURL atomically:YES encoding:encoding error:&error];
> if (!success)
> {
> [NSApp presentError:error];
> return NO;
> }
>
> Aaron
>
> On Jun 23, 2012, at 10:50 AM, Martin Hewitson wrote:
>
>> Dear list,
>>
>> I have an interesting bug report from a user of an app of mine. The app manages files and allows the user to edit them. When they save the project each file is saved to disk (if necessary). They are experiencing what appears to be a false positive of writeToURL:atomically:encoding:error:. The file actually does save, but the error comes back non-nil and when presented says:
>>
>> "You don’t have permission to save the file “XXX” in the folder “YYY”.
>>
>> The piece of code I use is
>>
>> NSError *error = nil;
>> [content writeToURL:aURL atomically:YES encoding:encoding error:&error];
>> if (error) {
>> [NSApp presentError:error];
>> return NO;
>> }
>>
>> By giving the user a debug version of the app with lots of NSLog statements, we narrowed it down to the above code. So even though the file is saved, 'error' comes back non-nil.
>>
>> Has anyone seen such behaviour before, or does anyone have any idea how to further investigate this?
>>
>> Best wishes,
>>
>> Martin
>>
>>
>>
>>
>> _______________________________________________
>>
>> 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
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Hewitson
Albert-Einstein-Institut
Max-Planck-Institut fuer
Gravitationsphysik und Universitaet Hannover
Callinstr. 38, 30167 Hannover, Germany
Tel: +49-511-762-17121, Fax: +49-511-762-5861
E-Mail: email@hidden
WWW: http://www.aei.mpg.de/~hewitson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
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