Erik04/15/2020, 5:15 PM
The resulting context for the block is derived by merging the currentFrom thewith the specified
coroutineContext + context).
Returns a context containing elements from this context and elements from otherFrom these docs I conclude that any. The elements from this context with the same key as in the other one are dropped.
call replaces the one from the parent scope of
. So why does @Manuel Vivo write in his excellent article (https://medium.com/androiddevelopers/coroutines-patterns-for-work-that-shouldnt-be-cancelled-e26c40f142ad):
CoroutineExceptionHandlers don’t work as you’d expect when the context is used in withContext since the exception will be re-thrown.So how come that a thrown exception is handled by the parent exception handler (which might rethrow it) , instead of handled by the overridden exception handler?
araqnid04/15/2020, 5:47 PM
elizarov04/15/2020, 6:43 PM
. Not yet in master. It should now better explain the details and stress the fact that it is the only used for top-level uncaught exceptions. (Wrong link. See right one below)
Erik04/15/2020, 7:22 PM
docs too? Or maybe take this a step further and structure the
type hierarchy a bit more transparently? For example: a
cannot be replaced (at least not the one in the root scope). A
should not (or never?) be passed to
. And there are some other finicky details about what is possible, but doesn't work as it might seem, or shouldn't be done at all. Could a bit more sophisticated type structure protect users against misuse/mistakes?