I'm fairly religious about returning NSError objects up through my call stack and handling them a high level. But I always find myself in a quandary with -[NSManagedObjectContext executeFetchRequest:error:].
First, this method is almost always used at a very low level in my code, so I have a very deep call stack to hand it up through. This is annoying and really hurts readability when what should be a nice simple low level method name (example: -allEmployees) has an NSError parameter hung on the end of it. Doing it the Correct Way™, which is to return YES/NO for succeed/fail and returning the result by reference would be even uglier. Second, I've never seen -[NSManagedObjectContext executeFetchRequest:error:] return an error, and indeed I can think of no reason why it should unless the fetch request had a bad entity or predicate. And since I compose my predicates in code, this is a programming error. So, I'm wondering why I'm complicating my code so much for something that's more like an exception than an error. Maybe it's more appropriate to just handle this error at the low level, by immediately displaying it or using NSAssert(). Does anyone have a smart way of handling the error from -[NSManagedObjectContext executeFetchRequest:error:] ? _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
