@@ -116,12 +116,12 @@ public interface SendChannel<in E> {
116116 * ```
117117 * val events = Channel<Event>(UNLIMITED)
118118 * 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 */ }
121121 * }
122122 *
123123 * val uiUpdater = uiScope.launch(Dispatchers.Main) {
124- * events.consume { /* handle events */ }
124+ * events.consume { /* handle events */ }
125125 * }
126126 * // Stop the callback after the channel is closed or cancelled
127127 * events.invokeOnClose { callbackBasedApi.stop() }
@@ -145,7 +145,7 @@ public interface SendChannel<in E> {
145145 * It has proven itself as the most error-prone method in Channel API:
146146 *
147147 * - `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.
149149 * - It was used mostly from non-suspending APIs where CancellationException triggered
150150 * internal failures in the application (the most common source of bugs).
151151 * - Due to signature and explicit `if (ch.offer(...))` checks it was easy to
@@ -323,7 +323,7 @@ public interface ReceiveChannel<out E> {
323323 * It has proven itself as error-prone method in Channel API:
324324 *
325325 * - 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.
327327 * - It was used mostly from non-suspending APIs where CancellationException triggered
328328 * internal failures in the application (the most common source of bugs).
329329 * - Its name was not aligned with the rest of the API and tried to mimic Java's queue instead.
0 commit comments