NSManagedObjectContext: точка останова исключения останавливается при сохранении: метод, но нет журнала / сбоя / ошибки - PullRequest
48 голосов
/ 01 декабря 2011

Я использую CoreData в многопоточном iOS-приложении, и все, кажется, работает нормально - если я не включаю точку останова исключения в XCode.Всякий раз, когда я выполняю какую-либо работу с CoreData, точка останова останавливается на save: -методе на NSManagedObjectContext, но впоследствии ошибка NSE равна нулю.У меня также нет ничего в журнале (кроме: Catchpoint 2 (exception thrown).), приложение не падает, поэтому довольно сложно сказать, что идет не так.

Единственная подсказка, которую я имею, - это то, что у меня естьодин объект в updatedObjects: в моем NSManagedObjectContext - но в этом нет ничего плохого.

Мой вопрос очень похож на этот вопрос по stackoverflow , но единственный ответ там не 'помогите мне;Я почти уверен, что у меня там все освещено.

Что здесь может быть не так?Или есть другие возможности получить информацию об ошибке?

Большое спасибо!

EDIT : показать код довольно сложно.Я загружаю объекты с objectID, редактирую и сохраняю их в контексте, назначенном текущему потоку.Я уже проверил - контекст всегда корректен для текущего потока;каждый поток имеет свой собственный контекст, это не должно быть проблемой.Было бы даже полезно, если бы только кто-то мог сказать мне, как получить больше информации об этой ошибке / исключении - или если мне все равно придется позаботиться об этом.Мне кажется, что исключение ловится в методе `save´, поэтому, вероятно, это" нормальное "поведение?

Ответы [ 5 ]

73 голосов
/ 18 января 2012

Это нормальное поведение. CoreData использует исключение и внутреннюю обработку для некоторых своих программных потоков. Я говорил с людьми из CoreData об этом. Это может показаться странным, но это дизайнерское решение, которое они приняли давным-давно.

Когда вы нажимаете исключение, убедитесь, что в обратном следе нет вашего кода между вашим вызовом -[NSManagedObjectContext save:] и генерируемым исключением. Звонок -save: очень вероятно перезвонит в ваш код, например, если вы наблюдаете NSManagedObjectContextObjectsDidChangeNotification, и если вы делаете плохие вещи, когда обрабатываете это уведомление, очевидно, вы виноваты.

Если вы выходите из метода -save:, а возвращаемое значение равно YES, все хорошо.

Обратите внимание, что вы должны проверить возвращаемое значение, для не используйте error != nil для проверки на наличие ошибки. Правильная проверка:

NSError *error = nil;
BOOL success = [moc save:&error];
if (!success) {
    // do error handling here.
}
18 голосов
/ 15 марта 2013

Вы можете избежать этих бесполезных разрывов; как уже отмечали другие, это нормальное поведение CoreData (но очень раздражающее!)

  1. Удалить точку останова "Все исключения Objective C"
  2. Добавить символическую точку останова на objc_exception_throw
  3. Установить условие точки останова на (BOOL)(! (BOOL)[[(NSException *)$eax className] hasPrefix:@"_NSCoreData"])
  4. Мне также нравится добавлять действие, команду отладчика "po $ eax", которая обычно выводит подробности исключения

$ eax - правильный регистр для симулятора, $ r0 работает на устройствах. Вы можете создать две отдельные точки останова и включить / отключить их соответствующим образом.

См. Игнорировать определенные исключения при использовании контрольной точки Все исключения Xcode для исходного ответа

8 голосов
/ 25 февраля 2012

У меня была похожая проблема.В конце концов я выяснил проблему:

Я добавил наблюдателя в NSManagedObjectContextDidSaveNotification , который был освобожден без удаления из центра уведомлений.Когда его память была назначена какому-то другому объекту, центр уведомлений попытался вызвать этот объект и вызвал исключение, потому что не смог найти правильный селектор.Это исключение было «невидимым» по какой-то причине, но заставило CoreData вызвать свое собственное исключение.

Удачно размещенный removeObserver: вызов исправил проблему.

Надеюсь, что это можетпомогите кому-нибудь еще, кто сталкивается с этой ситуацией.

0 голосов
/ 31 мая 2018

Я боролся с той же проблемой, и я обнаружил, что координатор сгенерирует исключение при проблеме слияния.Я удалил свою политику слияния (по умолчанию это ошибка), и после этого указатель ошибки больше не равен нулю при вызове команды save.Это также дало мне уверенность, что мой код в порядке.

0 голосов
/ 05 мая 2016

У меня была похожая проблема в моем коде.В конце концов я обнаружил, что проблема была в том, что моя модель изменилась, а используемый EncryptedCoreData NSPersistentStoreCoordinator не был настроен для автоматической миграции, как я ожидал с MagicalRecord в прошлом.

Единственным симптомом была эта точка останова, без каких-либо других сообщений.Эта проблема была решена (временно) путем удаления и переустановки приложения и навсегда путем добавления версий модели и соответствующего ключа (NSMigratePersistentStoresAutomaticallyOption: true, NSInferMappingModelAutomaticallyOption: true) в мои настройки стека.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...