Erik
04/15/2020, 5:15 PMwithContext
docs:
The resulting context for the block is derived by merging the currentFrom thewith the specifiedcoroutineContext
usingcontext
(seecoroutineContext + context
).CoroutineContext.plus
CoroutineContext.plus
docs:
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.context
CoroutineExceptionHandler
in the context
in withContext(context)
call replaces the one from the parent scope of withContext
. 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?
araqnid
04/15/2020, 5:47 PMelizarov
04/15/2020, 6:43 PMCoroutineExceptionHandler
. 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)Erik
04/15/2020, 7:22 PMwithContext
docs too? Or maybe take this a step further and structure the CoroutineContext
type hierarchy a bit more transparently? For example: a CoroutineExceptionHandler
cannot be replaced (at least not the one in the root scope). A Job
should not (or never?) be passed to launch
or async
. 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?