Deleting a CoreData object, then calling [tableView reloadData] causes a SIGABRT

Question

I'm supporting deleting rows in a UIView that includes a tableView:

- (void)tableView:(UITableView *)tableView commitEditingStyle:(UITableViewCellEditingStyle)editingStyle forRowAtIndexPath:(NSIndexPath *)indexPath {
    if (editingStyle == UITableViewCellEditingStyleDelete) {
  [self.fetchedResultsController.managedObjectContext
            deleteObject:[self.fetchedResultsController
            objectAtIndexPath:indexPath]];
  NSError *error;
  if (![[self.fetchedResultsController managedObjectContext] save:&error]) {
   NSLog(@"Unresolved error %@, %@, %@", error, [error userInfo],
                    [error localizedDescription]);
  }
  else {NSLog(@"Apparently successful");}
  [self.tableView reloadData];
 }
}

When I try this out, I get the "Apparently successful" message in the console, but then a SIGABRT in configureCell. It's as though somewhere the object hasn't been deleted, and configureCell is trying to present a missing object. (When I re-run the app, though, the record is gone.)

Any thoughts?

Posting some more of your code would help us, especially your tableView:cellForRowAtIndexPath: method, which probably is the culprit here. — Mayjak, Aug 22 '10 at 18:27
Ok, here's what happens before crashing: - (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath { [...boilerplate stuff that won't fit in this comment...] [self configureCell:cell atIndexPath:indexPath]; return cell; } - (void)configureCell:(UITableViewCell*)cell atIndexPath:(NSIndexPath*)indexPath { NSManagedObject *mo = [fetchedResultsController objectAtIndexPath:indexPath]; int objtype = [[(Type *)[mo valueForKey:@"type"] globalid] intValue]; Then -- BOOM! — ed94133, Aug 23 '10 at 01:31

score 2 · Accepted Answer · answered Aug 22 '10 at 18:37

2

You should not have that [self.tableView reloadData] there when using a NSFetchedResultsController.

When you delete an object, the right NSFetchedResultsControllerDelegate method will be called for you, where you should take care of updating your table view.

Create an empty Navigation-based Application and check the Use Core Data for Storage checkbox. What you will get is an empty project that does all this correct. It will be a good example.

answered Aug 22 '10 at 18:37

Stefan Arentz

34,311
8
67
88

Hmm -- not sure about this. I removed [self.tableView reloadData] and the table did not update (row didn't disappear). When I closed the ViewController (a modal VC) and reopened it, I got the same SIGABRT. This is a ViewController that contains a UITableView as a property, implements . – ed94133 Aug 23 '10 at 01:25
Show more code then. And a SIGABRT also comes with a stack trace that will probably give a good hint. – Stefan Arentz Aug 23 '10 at 01:55
If the table did not update then you are not implementing the delegate methods for the `NSFetchedResultsController` correctly. @St3fan is correct in his answer. Showing the full error would also be helpful. – Marcus S. Zarra Aug 23 '10 at 23:48
I finally had a chance to look at this more carefully, and you're correct, I hadn't implemented NSFetchedResultsControllerDelegate properly -- the Apple docs were helpful getting me there. – ed94133 Sep 07 '10 at 08:01

Deleting a CoreData object, then calling [tableView reloadData] causes a SIGABRT

1 Answers1

Linked