Блок @catch не перехватывает исключения в режиме отладки

В дополнение к моему вопросу и упомянутому здесь решению: https://stackoverflow.com/a/19153387/260665 единственный способ решить проблему состоял в том, чтобы реализовать блок @try-@catch и изящно обрабатывать исключения, очищая результаты потоков в случае исключений.

Это мой блок try-catch:

    // These operations are meant to calculate statistics for the Task objects, now when the statistics are being calculated there are possibilities that the main thread might delete the ManagedObject from it's MOC and write to the store. Now this means that ManagedObjects here may not have an equivalent record back in the store to refer!
    // So, when the already faulted objects try to access it's properties, NSObjectInaccessibleException arises. For more details check the SO post: https://stackoverflow.com/questions/18828164/coredata-object-fault-in-independent-managedobjectcontext-vs-changes-in-persiste
    // Hence catching the exception and returning back no results is the best approach as of now!
    @try
    {
        CSStatistics *theStats = [self statisticsOperationFromDate:self.dateRange.fromDate
                                                            toDate:self.dateRange.toDate];
        [self setOutStatistics:theStats];

        if ([(NSObject*)[self resultDelegate] respondsToSelector:@selector(statisticsOperationCompletedWithOperation:)])
        {
            [(NSObject*)[self resultDelegate] performSelectorOnMainThread:@selector(statisticsOperationCompletedWithOperation:)
                                                               withObject:self
                                                            waitUntilDone:NO];
        }
    }
    @catch (NSException *exception)
    {
        DEBUGLog(@"Most probably a NSObjectInaccessibleException exception! - %@", exception);
        [self setOutStatistics:nil];    // We would not like to give out erroneous reports! Mind it!
    }
    @finally
    {

    }

Происходят странные вещи, мой блок try-catch отлично работает в дистрибутивной сборке, когда приложение падает в отладочной и выпускной сборках. Судя по всему, исключение при возбуждении где-то обрабатывается и не передается в блок @catch, а потребляется. Я не могу понять, где, поскольку Xcode не дает никаких дополнительных сведений об этом.

Это журнал в режиме отладки:

2013-10-23 14:33:07.293 CATSXT[64267:650b] *** Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault for '0x1912fc00 <x-coredata://6E14A109-8A14-4369-BBC5-468D790A8D9E/CSTask/p7562>''
*** First throw call stack:
(0x33af012 0x2d25e7e 0x2a4ba48 0x2a4b3f7 0x2a4b031 0x2a4aea6 0x10eb42e2 0x5e02d 0x242e00b 0x2a86fc4 0x5cc58 0x244c247 0x5d492 0x244c205 0x5d492 0x246d23c 0x2440c70 0x15c075 0x15caac 0x15c6dd 0x244e453 0x244e164 0x24daa31 0x601253f 0x6024014 0x60152e8 0x6015450 0x949b0e72 0x94998d2a)
libc++abi.dylib: terminate called throwing an exception

Некоторые гугления показали мне, что точка останова «Все исключения» приводит к такому поведению, но я также отключил эту точку останова. Теперь я все еще не могу понять, почему блок @catch не выполняется в сборках отладки и выпуска, но он отлично работает в сборках дистрибутива. Это не беспокоит пользователей рабочего приложения, но определенно вредит процессу разработки.

Любые выводы будут высоко оценены.


person Raj Pawan Gumdal    schedule 23.10.2013    source источник
comment
Вы говорите, что ваша программа работает отлично, когда возникает исключение? Обратите внимание, что единственным и допустимым действием после исключения является завершение работы приложения как можно скорее. Cocoa не является безопасным для исключений, а это означает, что после того, как где-то в Cocoa было создано исключение, ваша программа остается в поврежденном состоянии. Единственным исключением из этого правила является случай, когда вы полностью контролируете стек выполнения, и когда он не вводил какой-либо метод Cocoa, и где нет возможности для кого-либо изменить это, например, путем переопределения методов. .   -  person CouchDeveloper    schedule 23.10.2013
comment
У меня также была эта проблема. Вместо этого я использую NSError. попробуйте: stackoverflow.com/a/4654759/1186689   -  person KDeogharkar    schedule 23.10.2013
comment
Что ж, чтобы найти реальную причину исключения, вы можете выполнить поиск "exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault" в SO или в Интернете. Надеюсь, это дает некоторые идеи о том, как вы могли бы решить настоящую проблему.   -  person CouchDeveloper    schedule 23.10.2013
comment
@CouchDeveloper - Спасибо за ваш вклад. Я провел достаточно исследований, а затем обнаружил, что нет никакого способа избежать исключения. Ссылка, которую я разместил в своем вопросе, объясняет, почему исключение неизбежно. Тем не менее, ваше упоминание о том, что какао не является безопасным для исключений, кажется интересным, почему должны быть исключения и обработка исключений, если какао не является безопасным для исключений? Любые ссылки на то же самое, которые могли бы пролить больше света на это?   -  person Raj Pawan Gumdal    schedule 23.10.2013
comment
@Raj В Исключения и фреймворки Cocoa: фреймворки Cocoa, как правило, не защищены от исключений. Общая схема заключается в том, что исключения зарезервированы только для ошибок программиста, и программа, перехватившая такое исключение, должна вскоре после этого завершить работу.   -  person CouchDeveloper    schedule 23.10.2013
comment
Спасибо, теперь это кажется большей проблемой для меня. Я надеялся доверять исключениям, сейчас, похоже, нет способа справиться с этой проблемой - vs-changes-in-persiste" title="Ошибка объекта coredata в независимом контексте управляемого объекта по сравнению с изменениями в persiste"> stackoverflow.com/questions/18828164/ Что мне делать? В любом случае, я все еще ищу решение этой проблемы и надеюсь, что исключения обрабатываются безопасно.   -  person Raj Pawan Gumdal    schedule 23.10.2013
comment
@BaZinga - я не могу создать здесь свой собственный NSError, потому что исключения запускаются внутри фреймворка.   -  person Raj Pawan Gumdal    schedule 23.10.2013
comment
@Raj, я собираюсь предложить какой-нибудь возможный подход в вашем первый вопрос   -  person CouchDeveloper    schedule 23.10.2013