_PFBatchFaultingArray objectAtIndex：

Question

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上运行。

Answer 1

好的，我想我弄清楚了原因。它是NSFetchedResultsController中缓存的原因。这很糟糕。如果您甚至将NSSortDescriptor从升序更改为降序，则必须手动删除缓存。

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

删除缓存可以解决此问题。我想这可能就是为什么Apple停止使用它与UICollectionViewController。就是这样一个问题。

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

Answer 2

你真的没有给出任何猜测的足够信息......但是你在这里：

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。只有你知道，何时或何地可以进行更新。

Answer 3

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

修复方法是将该属性设置为可选，并且不要预取它。

示例：

如果'学生＆lt; ---＆gt;背包'是你的模特。

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

    ...

当背包为零时发生撞击。