-
-
Notifications
You must be signed in to change notification settings - Fork 45
Improved Connect DB error handling #3348
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
656fb87
6682ffe
ba12699
80f8734
0af2793
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -10,6 +10,7 @@ | |
| import org.commcare.logging.DataChangeLogger; | ||
| import org.commcare.models.database.EncryptedDatabaseAdapter; | ||
| import org.commcare.models.database.DbUtil; | ||
| import org.javarosa.core.services.Logger; | ||
|
|
||
| import static org.commcare.models.database.app.AppDatabaseSchemaManager.DB_VERSION_APP; | ||
| import static org.commcare.models.database.app.AppDatabaseSchemaManager.getDbName; | ||
|
|
@@ -44,6 +45,7 @@ public SQLiteDatabase getWritableDatabase() { | |
| try { | ||
| return super.getWritableDatabase(); | ||
| } catch (SQLiteException sqle) { | ||
| Logger.exception("Opening database failed", sqle); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: it might be useful to know what database is failing here from the messag like
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we'll be able to see that pretty easily from the stack trace, no? Like whether it comes from DatabaseAppOpenHelper, DatabaseConnectOpenHelper, etc.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am concerned that Crashlytics will club them together into one single issue or not as it might be valuable to know if this issue is happening for all Dbs or just one by getting the issue count. Although not sure whats the behaviour here on Crashlytics really, so fine to ignore it atm |
||
| DbUtil.trySqlCipherDbUpdate(key, context, getDbName(mAppId)); | ||
| return super.getWritableDatabase(); | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curious why are not we logging the underlying exceptions now for
crashDbcalls.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, interesting. I removed them because they were essentially just duplicates of the fatal exception that gets logged immediately after when the app crashes, but didn't think about the lost crash-causing exception. I'll pass it through so the crashing exception can wrap it and we can preserve the full stack while avoiding duplicate events.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
0af2793
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also something worth noting: I checked back 90 days and neither of the two related non-fatal exceptions had been logged a single time
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confused exactly which two non-fatals you are mentioning here.