9 
2012-06-15 17:53:25.532 BadgerNew[3090:707] *** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[_PFBatchFaultingArray objectAtIndex:]: index (0) beyond bounds (0)'
*** First throw call stack:
(0x353f688f 0x3779d259 0x353f6789 0x353f67ab 0x35d5fee3 0x5a5c9 0x59fd3 0x43819 0x32e63c8b 0x38153 0x38309 0x32e63c8b 0x4142d 0x32e63c8b 0x32ec363d 0x32ec35db 0x32ec2f15 0x32ec2c49 0x35d21 0x32e62cab 0x32e5c7dd 0x32e2aac3 0x32e2a567 0x32e29f3b 0x36fe922b 0x353ca523 0x353ca4c5 0x353c9313 0x3534c4a5 0x3534c36d 0x32e5b86b 0x32e58cd5 0x35a73 0x35a54)
terminate called throwing an exception(lldb)

问题是什么？

它在主要中止。所以我什至不知道是哪条线导致了这个。

提示：在模拟器上运行。在我的 iPhone 上运行。不能在我朋友的 iPhone 上运行。

4

3 回答 3

8

好吧，我想我知道为什么了。这是因为 NSFetchedResultsController 中的缓存。这很糟糕。如果您甚至将 NSSortDescriptor 从升序更改为降序，则必须手动删除缓存。

因此，当上下文发生变化并且缓存没有意识到这一点时，它会变得很生气并抛出像你看到的那样的错误。当您在 XCode 中构建时会发生这种情况：上下文尚未保存（并丢失其数据）但缓存认为它应该保存，因此当它以零数据重新启动时，它会感到惊讶并且不知道如何处理它。

删除缓存可以解决这个问题。我认为这可能是 Apple 停止将它与 UICollectionViewController 一起使用的原因。就是这么个问题。

编辑：检查行/部分是否不超过 NSFetchedResultsController 的相应计数不起作用，因为它再次认为数据应该在那里，但事实并非如此。

于 2013-08-05T06:28:40.507 回答
8

您没有提供足够的信息来进行任何猜测...但是您在这里：

  1. 你使用CoreData吗？有人认为您的 CoreData 包含数据，但当被问及没有时。当有人向 fetchedResultsController.fetchedObjects 询问第一个对象（崩溃报告中提到的索引 0）但不存在（超出崩溃报告中的边界 0）时，会发生崩溃
  2. “超出范围的索引”是与数组相关的通用错误说明。错误报告说有人要求数组的第一项（索引 0），但该数组是空的（边界 0）。那是一个崩溃。

修复是在您要求数据之前确保有数据。一种方法是检查

if ([myArray count] > index)
    value = [myArray objectAtIndex:index];

无论如何，我最好的猜测是 PFBatchFaultingArray 指的是 CoreData，这意味着没有简单的答案。

您是否遇到过身份验证失败，这迫使 CoreData 更新，但 FRC 仍指向旧数据？当“旧”frc 认为仍有与上次看起来一样多的数据时，会发生崩溃，但 CoreData 中的“新”数据实际上数量较少。然后自动 UITableView 更新将询问行的数据，该行不再存在 == 崩溃。然后，您需要在任何人尝试使用数据之前刷新您的 frcs。只有您会知道何时何地可以进行刷新。

于 2013-01-14T09:25:46.690 回答
1

如果您在 NSFetchRequest 上设置“propertiesToFetch”，并且如果这些属性在数据库中为零，那么您也会收到此错误。

解决方法是使该属性成为可选的，并且不要预取它。

例子：

如果 'Student<--->Backpack' 是你的模特。

    let fetchRequest = ...
    fetchRequest.propertiesToFetch = ["backpack"]

    ...

当背包为零时发生崩溃。

于 2015-06-01T15:49:28.123 回答