https://bugs.kde.org/show_bug.cgi?id=494223
Bug ID: 494223
Summary: Wishlist: More consistent crash and exception handling
on Android
Classification: Applications
Product: kdeconnect
Version: unspecified
Platform: Android
OS: Android 14.x
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: android-application
Assignee: cliabh...@gmail.com
Reporter: cliabh...@gmail.com
CC: andrew.g.r.hol...@gmail.com
Target Milestone: ---
SUMMARY
We should be consistent when catching exceptions and creating log messages from
those exceptions. Add more mechanisms for catching otherwise-uncaught
exceptions. Do what we can to show a simple message in the case of catastrophic
failure.
BACKGROUND
When a `Exception` such as `IOException` or `SecurityException` is thrown on
Android, we tend to do one of three things:
* Catch and suppress the exception
* Catch and log the exception to the device's logcat
* Ignore the exception and let it bubble up to whatever called our code
These correlate roughly to three kinds of situation where something happened
that we don't want to happen:
* We were doing something that is unreliable (like I/O)
* We made an assumption that is invalid in this case (like "a certificate is
signed" or "our app is in the foreground")
* Android won't let our app do what we ask it to do (like "allocate too much
memory" or "dereference null values")
SUGGESTION
Use consistent formatting for try-catch blocks. That means using the name
`ignore` or `ignored` if we don't care about an exception, and a short name
like 'ex' if we do.
Replace all direct calls to `android.util.Log` with a wrapper such as `SLF4J`
or `Timber`. Avoid logging the full stacktraces if they wouldn't help for
debugging. For commented-out logs, either delete them or uncomment them + make
them log to a deactivated logger.
Use consistent log tags instead of a mix of tags (e.g. the Device class should
not use both "KDE/Device" and "Device"). Consider matching the guidelines from
https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Using_Error_Messages
. Be mindful of how logs show up in developer tools like Android Studio and how
they would look when copied into a bug report.
Add some kind of
https://developer.android.com/reference/java/lang/Thread.UncaughtExceptionHandler
to each thread we control. Log and/or display a friendly message if the app is
about to crash. See if there's a way to have an intermediate step between
`KdeConnect::onCreate` and all of the `init`/`initialise*` calls so that we can
display a different initial UI (new activity? fragment? dialog? notification?)
if there's a serious error during initialisation. Also look at APIs like
https://developer.android.com/reference/android/app/ApplicationExitInfo#getTraceInputStream()
and maybe show those traces somewhere.
--
You are receiving this mail because:
You are watching all bug changes.
