Why is <https kotlin github io kotlinx coroutines kotlinx co kotlinlang #announcements

Why is callbackFlow still marked experimental? As far as I know this is the official way of wrapping another api emitting multiple value (register / unregister). If I want to write a library using

callbackFlow

does that mean that it may become binary incompatible in the future? Thanks.

bonus question the doc say

Copy code

try {
    sendBlocking(value)
} catch (e: Exception) {
    // Handle exception from the channel: failure in flow or premature closing
}

but I find it a bit unhelpful. when can sendBlocking fail? what am I supposed to do there? (aka = how should I handle it?)

Zach Klippenstein (he/him) [MOD]

12/11/2020, 4:02 PM

One way that call can fail if the channel is closed and you’re still trying to send to it from a different thread. If you’ve correctly set up your callback to be removed by using

awaitClose

, this is a race condition that might not happen very often.

Daniele Segato

12/11/2020, 5:11 PM

so basically I could catch + ignore the exception there.

Zach Klippenstein (he/him) [MOD]

12/11/2020, 5:35 PM

Yes, there’s an active bug for the issue that

offer

throws when the channel is closed instead of returning false.

If you look at the implementation of

Observable.asFlow()

, it catches this exception and even has a comment linking to the bug.

louiscad

12/14/2020, 2:48 PM

Here's why it's still experimental : https://github.com/Kotlin/kotlinx.coroutines/issues/974

There might be additional reasons, but this is a big one.

4 Views