eygraber
01/20/2020, 9:00 PMFatal Exception: JobCancellationException: Job was cancelled
Is there any sort of global debugging I can turn on to try and track this down? If so, are any of them safe for a production environment?elizarov
01/21/2020, 7:13 AMlouiscad
01/21/2020, 7:41 AMelizarov
01/21/2020, 8:04 AMeygraber
01/21/2020, 8:34 AMlouiscad
01/21/2020, 9:48 AMThread.UncaughtExceptionHandler
instead of letting the exceptions/throwables be actually uncaught?elizarov
01/21/2020, 10:56 AMeygraber
01/22/2020, 7:35 PMkotlinx.coroutines.JobCancellationException: Job was cancelled; job=JobImpl{Cancelling}@57b9ffd
elizarov
01/24/2020, 7:53 AMlouiscad
01/24/2020, 8:10 AMoffer
throwing before called after close, but before callback unregistering had a chance to happen.
Last time I had the issue, this was the culprit.
It's even nastier when that happens in non suspending function that is called from suspending function as the program/app doesn't crash, but some code is not executed, and you don't know why, until you hopefully find some code was calling offer
on a cancelled/closed channel (e.g. because the scope of an actor
was closed, or whetever).
As a reminder, this related issue has been reported almost a year ago: https://github.com/Kotlin/kotlinx.coroutines/issues/974#issuecomment-577732745
This would be less of an issue if there was an inspection, or a checked exception that the compiler would enforce, but that's not the case, and that makes code unsafe until people realize the issue.
Also, the example in the documentation of callbackFlow
promotes an unsafe example as when there's asynchrony in callback unregistering, or multiple threads involved (like so often on Android and in the JVM), the offer
call would crash in the cases there was a callback happening at that time.
So yes, I'm trying to urge you to treat that as a design issue rather than just an "enhancement", and to fix that before Kotlin 1.4, by whatever mean (warning at use site is very conservative, but better than nothing).eygraber
01/24/2020, 9:32 AMoffer
(for better or for worse) and to handle each case would be a giant undertaking.
Granted, I never read the docs closely enough to notice the caveat about throwing if it's closed, but I assumed it was a safe call because it returns Boolean.
Going to post this (slightly modified) in the issue as well.louiscad
01/24/2020, 9:48 AMeygraber
01/24/2020, 9:52 AMlouiscad
02/09/2020, 8:20 PM