Always throw an exception for a core data error that prevents us from initializing Tracks. #198
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…hat in some cases, NSGetUncaughtExceptionHandler is not nil when we expect it to be, and thus we are unable to get information about why the data model is not able to set up correctly
MichelleTessier
requested review from
jleandroperez,
astralbodies and
bjhomer
and removed request for
astralbodies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.