ScopeProvider.coroutineScope
: Deliver lifecycle exceptions to CoroutineExceptionHandler
instead of throwing at call-site.
#632
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.
Change
ScopeProvider.coroutineScope
throwing behavior when accessing it before scope is active, or after scope is inactive.Instead of throwing at call site, we deliver
CoroutineScopeLifecycleException(message: String, cause: OutsideScopeException)
to theCoroutineExceptionHandler
installed atRibCoroutinesConfig.exceptionHandler
.Note
cause
is always non-null, and it's eitherLifecycleNotStartedException
orLifecycleEndedException
.Motivation
Suppose you have an interactor that starts subscribing to an Rx stream asynchronously.
It is possible that this Rx subscription will be triggered after interactor's already inactive. In that case, subscription will be No-Op.
This code is incorrect:
Interactor
is attempting to do work after it's inactive. In other words,runLater
does not respect the interactor lifecycle. Still, considering this is some legacy code being migrated from Rx to Coroutines, the new code would look like the following.Unlike the Rx counterpart, this code will sometimes fatally throw. If
ScopeProvider.coroutineScope
is called after the scope's inactive, it will throwLifecycleEndedException
at call site.Calling
coroutineScope
outside of lifecycle bounds is incorrect, but in order to allow for a smoother Rx migration to Coroutines, we are changing current implementation to deliver the exception to theCoroutineExceptionHandler
instead of throwing at call site.If some app decides to override the default behavior of crashing (in JVM/Android) in face of attempts to obtain coroutineScope when lifecycle is not active, one can customize
RibCoroutinesConfig.exceptionHandler
at app startup: