核心数据 - 创建NSFetchedResultsController

运行崩溃时，我使用的是TableViewController类，很像当你开始在Xcode新的主从应用程序项目时创建的。因此，我使用了预先填充在TableViewController类中的相同代码供我自己使用。然而，我得到一个运行时崩溃，我不知道为什么。我在我的应用的另一个类中使用了这个确切的代码，它完美地工作。核心数据 - 创建NSFetchedResultsController

- (NSFetchedResultsController *)fetchedResultsController 
{ 
    if (_fetchedResultsController != nil) { 
     return _fetchedResultsController; 
    } 

    NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init]; 
    // Edit the entity name as appropriate. 
    NSEntityDescription *entity = [NSEntityDescription entityForName:@"Binder" inManagedObjectContext:[appDelegate managedObjectContext]]; 
    [fetchRequest setEntity:entity]; 

    // Edit the sort key as appropriate. 
    //NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"timeStamp" ascending:NO]; 
    //NSArray *sortDescriptors = @[sortDescriptor]; 

    //[fetchRequest setSortDescriptors:sortDescriptors]; 

    // Edit the section name key path and cache name if appropriate. 
    // nil for section name key path means "no sections". 

//This is where it crashes 
    NSFetchedResultsController *aFetchedResultsController = [[NSFetchedResultsController alloc] initWithFetchRequest:fetchRequest managedObjectContext:[appDelegate managedObjectContext] sectionNameKeyPath:nil cacheName:@"Master"]; 
//End crash 
    aFetchedResultsController.delegate = self; 
    self.fetchedResultsController = aFetchedResultsController; 

    NSError *error = nil; 
    if (![self.fetchedResultsController performFetch:&error]) { 
     // Replace this implementation with code to handle the error appropriately. 
     // abort() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development. 
     NSLog(@"Unresolved error %@, %@", error, [error userInfo]); 
     abort(); 
    } 

    return _fetchedResultsController; 
}

我不确定其他代码片段包含在这里。当崩溃发生时，输出不会告诉我任何东西，并且Xcode跳转到主线程的这部分：

libsystem_kernel.dylib`__kill: 
0x972893b0: movl $786469, %eax 
0x972893b5: calll 0x9728b4c2    ; _sysenter_trap 
0x972893ba: jae 0x972893ca    ; __kill + 26 //This is highlighted 
0x972893bc: calll 0x972893c1    ; __kill + 17 
0x972893c1: popl %edx 
0x972893c2: movl 27739(%edx), %edx 
0x972893c8: jmpl *%edx 
0x972893ca: ret  
0x972893cb: nop

有什么想法？感谢

来源

2013-03-29 Nick

从什么你认为这是崩溃发生的地步？你有没有设置一个例外断点？如果是，那么在调试控制台中可以看到异常之前，您可能需要继续执行一次或两次。调试堆栈的外观如何，以及调试控制台中的错误消息是什么？ –

是的，我设置了一个异常断点。断点设置为“On Catch”，尽管当我将它设置为“On Throw”时它停在同一个点上。但是，当发生异常断点时，我会继续执行，然后停止在我发布的第二位代码处。调试控制台中唯一的是'（lldb）' – Nick

如果将缓存设置为'nil'会发生什么？ – Mundi

由于@flashfabrixx，问题是，我没有使用排序描述符和他们用的是NSFetchedResultsController时需要。一旦我添加了排序描述符，一切都很完美。

来源

2013-03-31 03:32:32 Nick

好吧，你正在做的唯一非标准的事情是，你正在使用从应用程序的委托管理对象上下文。这真的不建议，因为很多原因。

试图通过增加一个context属性的主控制器，并使用此背景下，以创建获取结果控制器（既为获得该实体的引用，为FRC创建）改变这一点。

最后，确保你的模型的确包含一个有效的Binder实体。

来源

2013-03-29 21:03:47 Mundi

标准方法是将本地托管对象上下文设置为应用程序委托的副本。无论如何，标准的方式只有一个上下文。所以，除非你与他们中的两个或更多人争执并改变应用程序委托中的一个，否则应该没有问题。不直接使用应用程序委托引用的好理由是什么？ –

嗯，其中一个是你从应用程序委托中调用getter，每次效率都不高。另一个是，这可能会返回'nil'，就像这里似乎是这样。 “很多很好的理由”超出了这个问题的范围。 – Mundi

啊，对，从应用程序委托调用getter当然不如从自己调用getter有效。对不起，问了。但是，如果应用程序代表中的MOC实际上是零，那么这个问题是否会对性能产生可测量的影响还远远不存在问题。 –

传递一个nil管理对象上下文initWithFetchRequest:managedObjectContext:sectionNameKeyPath:cacheName:会抛出异常。我很惊讶你没有看到控制台日志中的任何内容。

尝试NSAssert()以验证您的MOC和Binder实体均为非零。

如果您的NSFetchedResultsController中的缓存名称已用于其他FRC，除非两个控制器的提取请求相同，否则您将看到一个错误。设置一个nil（或不同的）cacheName:，看看你是否得到不同的结果。

来源

2013-03-29 21:22:53

当它传递给'initWithFetchRequest'时，我的MOC不是'nil'。我甚至在' - （void）viewDidLoad'中更改为'managedObjectContext = [appDelegate managedObjectContext];'以便我可以看到MOC的内存地址以查看它不是'nil'我从来没有使用'NSAssert（） '之前，但我认为我正确地设置了它。我做了NSAssert（managedObjectContext！= nil，@“No MOC”）;'和'NSAssert（entity！= nil，@“No entity”）;'并且它通过两个NSAsserts，所以我猜这意味着既不是' nil'。为'cacheName：'设置'nil'给出了相同的结果。 – Nick

核心数据 - 创建NSFetchedResultsController

回答

相关问题