This PR throws an exception with error information for core data errors that prevent us from initializing tracks, instead of using an abort().
On our first attempt to throw this exception, so that we could get more information in Sentry in the Day One iOS project, @jleandroperez attempted to only throw the exception if NSGetUncaughtExceptionHandler() was nil, hoping to cause minimal changes for other apps that may have employed an exception handler.
However, it appears that at least in the case of the Day One app, NSGetUncaughtExceptionHandler is not nil when we expect it to be, and thus, abort() is called instead of throwing an exception with a more detailed error message.
I suspect this may be related to when Sentry is used. I cannot confirm this in XCode builds, but given that we are seeing the abort() line in Sentry still being called, this is what we expect is happening.
In Day One, in Sentry, we are seeing the abort() line still called here, and thus we are unable to get information about why the data model is not able to set up correctly. We are seeing a large number of crashes (likely happening when the app is in the background) that appear to be caused by this line, so we would like to figure out why this is happening.
This PR throws an exception with error information for core data errors that prevent us from initializing tracks, instead of using an abort().
On our first attempt to throw this exception, so that we could get more information in Sentry in the Day One iOS project, @jleandroperez attempted to only throw the exception if NSGetUncaughtExceptionHandler() was nil, hoping to cause minimal changes for other apps that may have employed an exception handler.
However, it appears that at least in the case of the Day One app, NSGetUncaughtExceptionHandler is not nil when we expect it to be, and thus, abort() is called instead of throwing an exception with a more detailed error message.
I suspect this may be related to when Sentry is used. I cannot confirm this in XCode builds, but given that we are seeing the abort() line in Sentry still being called, this is what we expect is happening.
In Day One, in Sentry, we are seeing the abort() line still called here, and thus we are unable to get information about why the data model is not able to set up correctly. We are seeing a large number of crashes (likely happening when the app is in the background) that appear to be caused by this line, so we would like to figure out why this is happening.