Implement receiveOrClosed for channels and select clause
See original GitHub issueWe need receiveOrClosed
method on top of channels and onReceiveOrClosed
for select
which will have return type Either<E, CloseToken>
.
Currently, pattern to work with channels always has the following form which is clumsy and obfuscates code:
try {
source.onReceive { ... }
} catch (e: ClosedReceiveChannelException) {
// source is closed
}
The better alternative may be
source.onReceiveOrClosed {
when (it) {
CloseToken -> // end up consumption
_ -> // proceed normally
}
}
For implementation to be efficient we need inline classes (https://github.com/Kotlin/KEEP/issues/104)
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (6 by maintainers)
Top Results From Across the Web
How to safely select across channels where some may get ...
The outstanding proposal is to add receiveOrClose function and onReceiveOrClosed clause for select that would make writing code like this ...
Read more >ReceiveChannel - Javadoc.io
Clause for select expression of ReceiveChannel.receive suspending function that selects with the element that is received from the channel.
Read more >Select expression (experimental) - Kotlin
The onReceive clause in select fails when the channel is closed causing the corresponding select to throw an exception. We can use ......
Read more >Fencing off go: liveness and safety for channel-based ...
This restriction allows us to implement bounded verification ... Select. The select construct in Go encodes a form of guarded.
Read more >Diff - platform/external/kotlinx.coroutines - Google Git
+ * All operators on channels (that were prone to coroutine leaks) are deprecated in the ... + * Implemented `onTimeout` clause for...
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
It will be added to coroutines 1.5.0 under
receiveCatching
andonReceiveCatching
names.It’s already implemented and merged, the rationale of naming is explained in this comment
Let me clarify that the considerable fraction of value is going to come from support for
onReceiveOrClosed
clause inselect
expression. With that you can write operations on multiple channels with less boilerplate, without having to deal with concurrency, and with ability to code any behavior on the close of any of the source channels.Note, that when we have
channel.job.onJoin
you still will NOT be able to useonJoin
inselect
together withonReceive
, e.g this:will not work as expected. We shall make sure it fails fast in this case with a clear error message.
Another note, is that we should not actually expose
CloseToken
in public API, since trying to send this token over another channel will lead to unpredictable results, so we shall encapsulate it by introducing a specialValueOrClosed<T>
type (that will be implement asinline class
in the future).