subdigital/nsscreencast — pull request #2 by andrewsardone (2012-10-08 01:40:59+00:00)
Title: Fix error signaling when executing fetch request

`-[NSManagedObjectContext executeFetchRequest:error:]` does not necessarily signal an error/non-error result based on the non-nil/nil state of the `NSError` pointer. According to the `NSManagedObjectContext` documentation, the return value of `executeFetchRequest:error:` is:

> An array of objects that meet the criteria specified by request fetched from the receiver and from the persistent stores associated with the receiver’s persistent store coordinator. **If an error occurs, returns nil.** If no objects match the criteria specified by request, returns an empty array.

(emphasis mine, via [`executeFetchRequest:error:` docs][nsmocdocs])

Yes, this is clunky and unexpected, but it's the conventional use of `NSError` for error signaling. See the *Handling Error Objects Returned from Methods* section of Apple's *Error Handling Programming Guide*, specifically:

> **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.

(via Apple's [Error Handling Programming Guide][errorguide]).

[nsmocdocs]: https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObjectContext_Class/NSManagedObjectContext.html
[errorguide]: http://developer.apple.com/library/ios/#DOCUMENTATION/Cocoa/Conceptual/ErrorHandlingCocoa/CreateCustomizeNSError/CreateCustomizeNSError.html