Sam
02/20/2023, 5:59 PMstreetsofboston
02/20/2023, 6:24 PMSam
02/20/2023, 6:27 PMawait
and receive
, but also various Java APIs. Not bugs per se, just other ways of using the same exception supertype.streetsofboston
02/20/2023, 6:37 PMSam
02/20/2023, 6:37 PMstreetsofboston
02/20/2023, 6:43 PMephemient
02/20/2023, 10:57 PMfranztesca
02/20/2023, 11:50 PMSam
02/21/2023, 8:41 AMCancellationException
in the latter case. When the channel is simply closed, they instead throw dedicated “closed channel” exceptions that don’t extend CancellationException
, which I think is strongly preferable. Actually I find concept of a “cancelled” channel to be unnecessary and even destructive now that we have structured concurrency. Your suggestion of using trySend/receiveCatching as a workaround is a nice solution, thank you 🙇ensureActive
check does change the behaviour there. I’ll have a think about it and see if I can come up with some examples and/or mitigations.Oliver.O
03/20/2023, 10:20 PMsuspend fun Throwable.cancelsThisCoroutine() = this is CancellationException && !coroutineContext.isActive
suspend fun Throwable.propagateCancellation() {
if (cancelsThisCoroutine()) {
throw this
}
}
and use the latter like so?
try {
// ...
} catch (throwable: Throwable) {
throwable.propagateCancellation()
// log exception
}
Sam
03/21/2023, 10:27 AMensureActive
in an additional type check:
if (throwable is CancellationException) {
coroutineContext.ensureActive()
}
Slightly different in behaviour but much the same result. Personally I’m still hesitating as to whether I think having the cancellation suppress other errors is a problem or not… perhaps it varies from case to case.Oliver.O
03/21/2023, 11:14 AMensureActive()
preserves the original CancellationException
. Otherwise you'd not only lose the original message but also the list of suppressed exceptions attached to the original `CancellationException`: Exceptions aggregationSam
03/21/2023, 11:16 AM