Why is <callbackFlow> still marked experimental? As far as I know this is the official way of wrappi...

# announcements

[Daniele Segato]

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.

[Daniele Segato]

bonus question

the doc say

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]]

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]

so basically I could catch + ignore the exception there.

[Zach Klippenstein (he/him) [MOD]]

Yes, there’s an active bug for the issue that offer throws when the channel is closed instead of returning false.

[Zach Klippenstein (he/him) [MOD]]

If you look at the implementation of Observable.asFlow(), it catches this exception and even has a comment linking to the bug.

[louiscad]

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

[louiscad]

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