@@ -116,12 +116,12 @@ public interface SendChannel<in E> {
116
116
* ```
117
117
* val events = Channel<Event>(UNLIMITED)
118
118
* callbackBasedApi.registerCallback { event ->
119
- * events.trySend(event)
120
- * .onClosed { /* channel is already closed, but the callback hasn't stopped yet */ }
119
+ * events.trySend(event)
120
+ * .onClosed { /* channel is already closed, but the callback hasn't stopped yet */ }
121
121
* }
122
122
*
123
123
* val uiUpdater = uiScope.launch(Dispatchers.Main) {
124
- * events.consume { /* handle events */ }
124
+ * events.consume { /* handle events */ }
125
125
* }
126
126
* // Stop the callback after the channel is closed or cancelled
127
127
* events.invokeOnClose { callbackBasedApi.stop() }
@@ -145,7 +145,7 @@ public interface SendChannel<in E> {
145
145
* It has proven itself as the most error-prone method in Channel API:
146
146
*
147
147
* - `Boolean` return type creates the false sense of security, implying that `false`
148
- * is returned instead of throwing an exception.
148
+ * is returned instead of throwing an exception.
149
149
* - It was used mostly from non-suspending APIs where CancellationException triggered
150
150
* internal failures in the application (the most common source of bugs).
151
151
* - Due to signature and explicit `if (ch.offer(...))` checks it was easy to
@@ -323,7 +323,7 @@ public interface ReceiveChannel<out E> {
323
323
* It has proven itself as error-prone method in Channel API:
324
324
*
325
325
* - Nullable return type creates the false sense of security, implying that `null`
326
- * is returned instead of throwing an exception.
326
+ * is returned instead of throwing an exception.
327
327
* - It was used mostly from non-suspending APIs where CancellationException triggered
328
328
* internal failures in the application (the most common source of bugs).
329
329
* - Its name was not aligned with the rest of the API and tried to mimic Java's queue instead.
0 commit comments