As Roland indicated, yes, this is a general statement. It would be advisable to read the Error Handling Programming Guide, which includes, among other things:
"Important Success or failure is indicated by the return value of the method. Although Cocoa methods that indirectly return error objects in the Cocoa error domain are guaranteed to return such objects if the method indicates failure by directly returning nil or NO, you should always check that the return value is nil or NO before attempting to do anything with the NSError object." More at: https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/ErrorHandlingCocoa/ErrorHandling/ErrorHandling.html -Conrad On Jun 23, 2012, at 10: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 _______________________________________________ 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
