_PFBatchFaultingArray objectAtIndex:

问题:

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) 

What is the problem?

It aborts right at main. So I don't even know which line cause this.

Hint: Run on simulator. Run on my iPhone. Doesn't run on my friend's iPhone.

回答1:

You relly didn't give enough info for any guesses... but here you are:

1. Do you use CoreData? Someone thinks your CoreData contains data, but when asked there's none. Crash would happen, when someone asks fetchedResultsController.fetchedObjects for first object (index 0 as mentioned in crash report), but that doesn't exists (beyond bounds 0 in crash report)
2. "index beyond bounds" is a generic error note related to arrays. Error reports says that someone was asking for first item of array (index 0), but that array was empty (bounds 0). That's a crash.

Fix is to make sure there is data before you ask for it. One way is to check

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

Anyways, my best guess is that PFBatchFaultingArray refers to CoreData and that means there are no easy answers.

Did you have e.g. authentication failure, which forced CoreData update, but FRCs are still pointing to old data? Crash would happen, when "old" frc thinks there still as much data as last time it looked, but the "new" data in CoreData is actually less in number. Then automatic UITableView update would be asking data for row, which doesn't exists any more == crash. Then you need to refresh your frcs BEFORE anyone tries to use the data. Only you will know, when or where that refresh can be done.

回答2:

Ok, I think I figured out why. It's 'cause of the cache in NSFetchedResultsController. It's crappy. If you even so much as change the NSSortDescriptor from ascending to descending, you have to delete the cache manually.

So when the context changes and the cache doesn't realize this, it gets pissy and throws errors like the one you see. This can happen when you hit build in XCode: the context hasn't saved (and loses its data) but the cache thinks it should have so when it restarts with zero data, it gets surprised and doesn't know how to handle it.

Removing the cache gets rid of this problem. I think this may be why Apple stopped using it with UICollectionViewController. Just such a problem.

EDIT: checking for if the row/section doesn't exceed the respective count of NSFetchedResultsController doesn't work, because again, it THINKS the data should be there but it isn't.

回答3:

If you are setting a "propertiesToFetch" on the NSFetchRequest, and if those properties are nil in the database, then you'll get this error as well.

The fix is to make that property optional, and don't prefetch it.

Example:

if 'Student<--->Backpack' is your model.

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

    ...

The crash happens when backpack is nil.