Skip to content
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.

Sign up for GitHub

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

Dispatcher catches and rethrows Throwable instead of Exception to avoid swallowing errors #1894

Merged
merged 1 commit into from
Nov 4, 2024
Merged

Dispatcher catches and rethrows Throwable instead of Exception to avoid swallowing errors #1894

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion purchases/src/main/kotlin/com/revenuecat/purchases/common/Dispatcher.kt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@
val commandHandlingExceptions = Runnable {
try {
command.run()
} catch (@Suppress("TooGenericExceptionCaught") e: Exception) {
} catch (@Suppress("TooGenericExceptionCaught") e: Throwable) {

Check warning on line 68 in purchases/src/main/kotlin/com/revenuecat/purchases/common/Dispatcher.kt

View check run for this annotation

Codecov / codecov/patch

purchases/src/main/kotlin/com/revenuecat/purchases/common/Dispatcher.kt#L68 

Added line #L68 was not covered by tests
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch!!!

But yeah good thinking on those drawbacks... If we want to be safe, I think we could instead, catch the error and log it but not propagate it and maybe add a new Diagnostics event for these Throwable + not Exception errors.

On the other hand, I believe this is used only in a few places, so maybe we can fix those so we just propagate the Throwable as a "normal" exception, even if it's not an exception that we can propagate through the normal error channels... Wdyt?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea I think we have 2 choices:

  1. Log an error, but don't rethrow the Throwable. The app would still hang, but it's better than silently hanging.
  2. Rethrow the Throwable. The app would crash, but that means the chance is higher we come to know of it and get to fix it.

I don't know what we prefer in terms of developer experience. Option 1 might leave the developer confused, unless they happen to see the error log. Option 2 might leave them annoyed that the app crashed.

I'm slightly leaning towards option 2, but I'm okay with 1 too. @tonidero @vegaro what do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right, so I think if we want to minify risk, we basically would need to make sure we catch any Throwable's that we weren't caching before and map them to exceptions we can display through the API.

Admittedly that's more work, but probably the safest... Having said that, I wouldn't expect this to uncover many issues and if it does, there is probably something very wrong that wasn't working, so maybe it's ok to just do option 2 (which is what's implemented in this PR). I'm ok with this option as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am down to go with option 2. If an app starts to crash is very likely due to a bug in our code that we need to be able fix.

I remember I fixed a very similar issue in the past where exceptions were getting swallowed and it helped us uncover very important issues in our code

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, since we're all okay with option 2, I'd say let's go that route. That indeed maximizes visibility of any potential issues this might uncover.

I have marked the PR as ready for review.

errorLog("Exception running command: $e")
// We propagate the exception to the main thread to be sure it's not swallowed.
mainHandler?.post {
Expand Down