Skip to content

Conversation

fioan89
Copy link
Collaborator

@fioan89 fioan89 commented Aug 28, 2025

The try/catch block raised NPE in the notify if another exception was raised after the context containing the URL was reset - so that means an error in the onConnect handler. In addition, some of the reset steps were moved after onConnect to make sure they execute only if onConnect callback is successful.

Because of the fault in how the steps were arranged, the original exception was never logged instead a misleading NPE was treated by the coroutine's exception handler.

The try/catch block raised NPE in the `notify` if another exception was raised
after the context containing the URL was reset - so that means an error in the onConnect
handler. In addition, some of the reset steps were moved after onConnect to make sure they
execute only if onConnect callback is successful.

Because of the fault in how the steps were arranged, the original exception was never logged
instead a misleading NPE was treated by the coroutine's exception handler.
@fioan89
Copy link
Collaborator Author

fioan89 commented Aug 28, 2025

I'm putting this on draft because when I tried to test a scenario where onConnect raised an exception Toolbox refused to show the snackbar with the error requested by the notify. I think it has something to do with calling lambdas passed as method references in the coroutines that are cancelled in the end. If I replace the "notify" with a simple showSnackbar call everything is fine. Of course, notify does a bit more than that so I need to either find a nother way to share/reuse that implementation in a different way, or understand why method references don't work too well in coroutines that become canceled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant