Exceptions eaten after coroutine has been cancelled
See original GitHub issueval job = launch {
withContext(NonCancellable) {
delay(100)
println("Throwing exception now...")
throw Exception()
}
}
job.cancelAndJoin()
Above code will not throw any exception (println will be executed, but exception not thrown).
Is that expected behavior? I would imagine exceptions would always have to be thrown, even after corotuine has been cancelled.
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Exceptions in coroutines. Cancellation and Exceptions in…
When a coroutine fails with an exception, it will propagate said exception up to its parent! Then, the parent will 1) cancel the...
Read more >In-Depth Guide to Coroutine Cancellation & Exception Handling
With Kotlin's coroutines, we have an amazing framework to perform async operations. However, it's not as easy as it first seems.
Read more >Coroutine exceptions handling | Kotlin
Here we look at what happens if an exception is thrown during cancellation or multiple children of the same coroutine throw an exception....
Read more >How to fix Kotlin JobCancellationException? - Stack Overflow
Finally, I found what causes the Exception and the issue address is flowing: kotlin.coroutines.channels.awaitClose: JobCancellationException.
Read more >Kotlin Coroutines(Part — 4): Cancellation | by Aditi Katiyar
When we cancel a job, it throws a CancellationException. Unlike other exceptions, it does not crash the program. It is a silent exception...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
You have to refer to documentation, always.
Thanks for the answers. I’m closing this as it looks like a dupe of #333.