核心數據 - 創建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

回答

相關問題