0

With further to my question and it's solution mentioned here: https://stackoverflow.com/a/19153387/260665 the only way to solve the problem was to implement @try-@catch block and gracefully handle the exceptions by clearing off the results of the threads in case of exceptions.

This is my try-catch block:

    // 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
    {

    }

Strange things happen, my try-catch block works perfectly well in distribution build where as the app crashes in debug and release builds. Apparently, the exception when raised is handled somewhere and it is not passed to the @catch block but it is consumed instead. I cannot figure out where as Xcode gives no further details of the same.

This is the log in debug mode:

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

Some googling showed me that the 'All Exceptions' breakpoint results in such behavior but I have disabled that breakpoint as well. Now I still cannot figure out why @catch block is not executed in debug and release builds but it works perfectly well in distribution builds. This does not trouble the users of production app but it definitely hurts the development process.

Any leads would be much appreciated.

Community
  • 1
  • 1
Raj Pawan Gumdal
  • 7,132
  • 10
  • 55
  • 85
  • Are you saying your program works perfectly when an exception has been thrown? Notice, that the only and valid course of action after an exception is to terminate the app as soon as possible. Cocoa is not exception safe, which means that after an exception has been thrown somewhere within Cocoa, your program is left in a corrupted stated. The only exception to this rule is when you **fully** control the execution stack, and where it did not enter any Cocoa method, and where there is no possibility to for anyone to change this, for example through overriding methods. – CouchDeveloper Oct 23 '13 at 09:06
  • I also had this issue . I use NSError instead. try it : http://stackoverflow.com/a/4654759/1186689 – KDeogharkar Oct 23 '13 at 09:10
  • Well, in order to find the actual reason for the exception, you may search for `"exception 'NSObjectInaccessibleException', reason: 'CoreData could not fulfill a fault"` on SO or in the web. Hope, that gives some ideas how you might tackle the actual problem. – CouchDeveloper Oct 23 '13 at 09:20
  • @CouchDeveloper - Thank you for your inputs. I had done enough research and then found out that there was no way to avoid the exception. The link I posted in my question explains why exception is unavoidable. However, your mention about "Cocoa is not exception safe" seems to be interesting, why would there be exceptions and exception handling if cocoa is not exception safe? Any references for the same which might throw more light on it? – Raj Pawan Gumdal Oct 23 '13 at 10:13
  • 1
    @Raj In [Exceptions and the Cocoa Frameworks](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Exceptions/Articles/ExceptionsAndCocoaFrameworks.html#//apple_ref/doc/uid/TP40009045-SW1):"The Cocoa frameworks are generally not exception-safe. The general pattern is that exceptions are reserved for programmer error only, and the program catching such an exception should quit soon afterwards." – CouchDeveloper Oct 23 '13 at 10:44
  • Thank you, now that seems to be a bigger problem for me. I was hoping to trust on the exceptions, there seems to be no way of handling this problem now - http://stackoverflow.com/questions/18828164/coredata-object-fault-in-independent-managedobjectcontext-vs-changes-in-persiste What am I supposed to do? Anyhow, I am still looking for a solution to this problem and hope that exceptions are safely handled. – Raj Pawan Gumdal Oct 23 '13 at 10:57
  • @BaZinga - I cannot design my own NSError here because the exceptions are triggered from within the framework. – Raj Pawan Gumdal Oct 23 '13 at 11:01
  • 1
    @Raj, I'm going to suggest some possible approach in your [first question](http://stackoverflow.com/questions/18828164/coredata-object-fault-in-independent-managedobjectcontext-vs-changes-in-persiste/19153387#19153387) – CouchDeveloper Oct 23 '13 at 11:09

0 Answers0