什么是“正确的”？使用 NSManagedObjectContext 的 objectWithID 的方法：
文档指出：
...此方法始终返回一个对象。 持久存储中的数据 假定由 objectID 表示 存在——如果不存在，则返回 当您执行以下操作时，对象会抛出异常 访问任何属性（即，当 故障被解雇）。这样做的好处 行为是它允许你 创建并使用错误，然后创建 稍后或在单独的行中 上下文。
在Apple的“Core Recipes”示例应用程序中，该方法的结果用于填充NSFetchRequest，然后使用请求的结果，并带有这样的注释：
// first get the object into the context
Recipe *recipeFault = (Recipe *)[context objectWithID:objectID];
// this only creates a fault, which may NOT resolve to an object (for example, if the ID is for
// an objec that has been deleted already): create a fetch request to get the object for real
NSFetchRequest *request = [[[NSFetchRequest alloc] init] autorelease];
[request setEntity: [NSEntityDescription entityForName:@"Recipe" inManagedObjectContext:context]];
NSPredicate *predicate = [NSPredicate predicateWithFormat: @"(self == %@)", recipeFault];
[request setPredicate: predicate];
我见过很多示例（其他人的代码和苹果的“iClass”）其中直接使用来自 objectWithID 的结果 - 这意味着，它的属性将被访问并愉快地处理。
objectWithID总是应该被视为“maybe-this-exists”对象吗？
我这么问是因为我刚刚遇到这个问题并且并没有反对它的存在。
the docs state:
...This method always returns an object.
The data in the persistent store
represented by objectID is assumed to
exist—if it does not, the returned
object throws an exception when you
access any property (that is, when the
fault is fired). The benefit of this
behavior is that it allows you to
create and use faults, then create the
underlying rows later or in a separate
context.
and in Apple's 'Core Recipes' sample app the result of the method is used to populate an NSFetchRequest, and the request's result is then used, with comments to that effect:
// first get the object into the context
Recipe *recipeFault = (Recipe *)[context objectWithID:objectID];
// this only creates a fault, which may NOT resolve to an object (for example, if the ID is for
// an objec that has been deleted already): create a fetch request to get the object for real
NSFetchRequest *request = [[[NSFetchRequest alloc] init] autorelease];
[request setEntity: [NSEntityDescription entityForName:@"Recipe" inManagedObjectContext:context]];
NSPredicate *predicate = [NSPredicate predicateWithFormat: @"(self == %@)", recipeFault];
[request setPredicate: predicate];
I have seen many examples (other's code, and apple's 'iClass') where the result from objectWithID is used directly - meaning, its properties are accessed and merrily processed along.
Should objectWithID always be treated as a 'maybe-this-exists' object?
I'm asking because I've just run into this and hadn't been fetching against its existence.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Apple 文档告诉您的不是假设对象存在是持久存储，仅仅因为返回了一个对象。
您可以像对待它一样对待它，访问其属性等等，因为在后台 Core Data 将访问数据存储来服务您的请求。但是，如果该对象在商店中不存在，您将收到异常。
这是 Apple 解释故障的文档（这就是
objectWithID:正在返回给您）。What the Apple documentation is telling you is not to assume that the object exists is the persistent store, just because an object is returned.
You can treat it as though it does, accessing its properties and so on, because in the background Core Data will access the data store to service your request. However, if the object doesn't exist in the store, you'll get an exception.
Here's Apple's documentation explaining faults (which is what
objectWithID:is returning to you).我发现这篇文章 通过 URI 安全地获取 NSManagedObject 包含一个很好的多合一方法，用于使用
objectWithID:获取对象，但如果发现有错误，则继续获取它。详细的方法在处理对象 URI 方面更进一步，但所提出的核心技术是对此问题中讨论的有用扩展。I found this article Safely fetching an NSManagedObject by URI to contain a nice all in one method for grabbing an object using
objectWithID:but if it's found to be a fault, to go ahead and fetch it. The method detailed goes a bit further in dealing with object URIs, but the core technique presented is a useful extension to the discussion in this question.