On Jun 24, 2012, at 1:35 PM, Martin Hewitson wrote: > 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
Yes that is a general statement. You should check the return value of the method and only if it indicates there's an error, check the error object. There is no guarantee that the error object was not set at some point during the method processing, even if that method eventually succeeds, nor that it's forced clear on success. Most such methods are nice enough to return BOOL so it's quite easy, attributesOfItemAtPath:error .. indeed it is not documented what it does in the case of error. I would probably only check the error object if that method returned nil and I would test to see if it does return nil if I give it a bad path or a directory I can't read or something to increase my comfort level. Would be nicer if that were documented of course. _______________________________________________ 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
