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 (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:
>> https://lists.apple.com/mailman/options/cocoa-dev/eeyore%40monsterworks.com
>>
>> This email sent to eey...@monsterworks.com
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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: martin.hewit...@aei.mpg.de
WWW: http://www.aei.mpg.de/~hewitson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
