Skip to content

Commit 88e8409

Browse files
InegoLouisCAD
authored andcommitted
Fix typos in docs (Kotlin#2098)
Co-authored-by: Louis CAD <[email protected]>
1 parent c0b741f commit 88e8409

File tree

9 files changed

+77
-77
lines changed

9 files changed

+77
-77
lines changed

docs/coroutine-context-and-dispatchers.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -625,7 +625,7 @@ fun main() = runBlocking<Unit> {
625625
In this example we launch a new coroutine in a background thread pool using [Dispatchers.Default], so
626626
it works on a different thread from the thread pool, but it still has the value of the thread local variable
627627
that we specified using `threadLocal.asContextElement(value = "launch")`,
628-
no matter on what thread the coroutine is executed.
628+
no matter which thread the coroutine is executed on.
629629
Thus, the output (with [debug](#debugging-coroutines-and-threads)) is:
630630

631631
```text

docs/exception-handling.md

+38-38
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ coroutine throw an exception.
2828
Coroutine builders come in two flavors: propagating exceptions automatically ([launch] and [actor]) or
2929
exposing them to users ([async] and [produce]).
3030
When these builders are used to create a _root_ coroutine, that is not a _child_ of another coroutine,
31-
the former builder treat exceptions as **uncaught** exceptions, similar to Java's `Thread.uncaughtExceptionHandler`,
31+
the former builders treat exceptions as **uncaught** exceptions, similar to Java's `Thread.uncaughtExceptionHandler`,
3232
while the latter are relying on the user to consume the final
3333
exception, for example via [await][Deferred.await] or [receive][ReceiveChannel.receive]
3434
([produce] and [receive][ReceiveChannel.receive] are covered later in [Channels](https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/channels.md) section).
@@ -246,7 +246,7 @@ CoroutineExceptionHandler got java.lang.ArithmeticException
246246

247247
### Exceptions aggregation
248248

249-
When multiple children of a coroutine fail with an exception the
249+
When multiple children of a coroutine fail with an exception, the
250250
general rule is "the first exception wins", so the first exception gets handled.
251251
All additional exceptions that happen after the first one are attached to the first exception as suppressed ones.
252252

@@ -296,8 +296,8 @@ CoroutineExceptionHandler got java.io.IOException with suppressed [java.lang.Ari
296296

297297
<!--- TEST-->
298298

299-
> Note, this mechanism currently works only on Java version 1.7+.
300-
Limitation on JS and Native is temporary and will be fixed in the future.
299+
> Note that this mechanism currently only works on Java version 1.7+.
300+
The JS and Native restrictions are temporary and will be lifted in the future.
301301

302302
Cancellation exceptions are transparent and are unwrapped by default:
303303

@@ -353,14 +353,14 @@ A good example of such a requirement is a UI component with the job defined in i
353353
have failed, it is not always necessary to cancel (effectively kill) the whole UI component,
354354
but if UI component is destroyed (and its job is cancelled), then it is necessary to fail all child jobs as their results are no longer needed.
355355

356-
Another example is a server process that spawns several children jobs and needs to _supervise_
357-
their execution, tracking their failures and restarting just those children jobs that had failed.
356+
Another example is a server process that spawns multiple child jobs and needs to _supervise_
357+
their execution, tracking their failures and only restarting the failed ones.
358358

359359
#### Supervision job
360360

361-
For these purposes [SupervisorJob][SupervisorJob()] can be used.
361+
The [SupervisorJob][SupervisorJob()] can be used for these purposes.
362362
It is similar to a regular [Job][Job()] with the only exception that cancellation is propagated
363-
only downwards. It is easy to demonstrate with an example:
363+
only downwards. This can easily be demonstrated using the following example:
364364

365365
<div class="sample" markdown="1" theme="idea" data-highlight-only>
366366

@@ -372,24 +372,24 @@ fun main() = runBlocking {
372372
with(CoroutineScope(coroutineContext + supervisor)) {
373373
// launch the first child -- its exception is ignored for this example (don't do this in practice!)
374374
val firstChild = launch(CoroutineExceptionHandler { _, _ -> }) {
375-
println("First child is failing")
376-
throw AssertionError("First child is cancelled")
375+
println("The first child is failing")
376+
throw AssertionError("The first child is cancelled")
377377
}
378378
// launch the second child
379379
val secondChild = launch {
380380
firstChild.join()
381381
// Cancellation of the first child is not propagated to the second child
382-
println("First child is cancelled: ${firstChild.isCancelled}, but second one is still active")
382+
println("The first child is cancelled: ${firstChild.isCancelled}, but the second one is still active")
383383
try {
384384
delay(Long.MAX_VALUE)
385385
} finally {
386386
// But cancellation of the supervisor is propagated
387-
println("Second child is cancelled because supervisor is cancelled")
387+
println("The second child is cancelled because the supervisor was cancelled")
388388
}
389389
}
390390
// wait until the first child fails & completes
391391
firstChild.join()
392-
println("Cancelling supervisor")
392+
println("Cancelling the supervisor")
393393
supervisor.cancel()
394394
secondChild.join()
395395
}
@@ -403,18 +403,18 @@ fun main() = runBlocking {
403403
The output of this code is:
404404

405405
```text
406-
First child is failing
407-
First child is cancelled: true, but second one is still active
408-
Cancelling supervisor
409-
Second child is cancelled because supervisor is cancelled
406+
The first child is failing
407+
The first child is cancelled: true, but the second one is still active
408+
Cancelling the supervisor
409+
The second child is cancelled because the supervisor was cancelled
410410
```
411411
<!--- TEST-->
412412

413413

414414
#### Supervision scope
415415

416-
For _scoped_ concurrency [supervisorScope] can be used instead of [coroutineScope] for the same purpose. It propagates cancellation
417-
in one direction only and cancels all children only if it has failed itself. It also waits for all children before completion
416+
Instead of [coroutineScope], we can use [supervisorScope] for _scoped_ concurrency. It propagates the cancellation
417+
in one direction only and cancels all its children only if it failed itself. It also waits for all children before completion
418418
just like [coroutineScope] does.
419419

420420
<div class="sample" markdown="1" theme="idea" data-highlight-only>
@@ -428,19 +428,19 @@ fun main() = runBlocking {
428428
supervisorScope {
429429
val child = launch {
430430
try {
431-
println("Child is sleeping")
431+
println("The child is sleeping")
432432
delay(Long.MAX_VALUE)
433433
} finally {
434-
println("Child is cancelled")
434+
println("The child is cancelled")
435435
}
436436
}
437437
// Give our child a chance to execute and print using yield
438438
yield()
439-
println("Throwing exception from scope")
439+
println("Throwing an exception from the scope")
440440
throw AssertionError()
441441
}
442442
} catch(e: AssertionError) {
443-
println("Caught assertion error")
443+
println("Caught an assertion error")
444444
}
445445
}
446446
```
@@ -452,21 +452,21 @@ fun main() = runBlocking {
452452
The output of this code is:
453453

454454
```text
455-
Child is sleeping
456-
Throwing exception from scope
457-
Child is cancelled
458-
Caught assertion error
455+
The child is sleeping
456+
Throwing an exception from the scope
457+
The child is cancelled
458+
Caught an assertion error
459459
```
460460
<!--- TEST-->
461461

462462
#### Exceptions in supervised coroutines
463463

464464
Another crucial difference between regular and supervisor jobs is exception handling.
465-
Every child should handle its exceptions by itself via exception handling mechanism.
466-
This difference comes from the fact that child's failure is not propagated to the parent.
467-
It means that coroutines launched directly inside [supervisorScope] _do_ use the [CoroutineExceptionHandler]
465+
Every child should handle its exceptions by itself via the exception handling mechanism.
466+
This difference comes from the fact that child's failure does not propagate to the parent.
467+
It means that coroutines launched directly inside the [supervisorScope] _do_ use the [CoroutineExceptionHandler]
468468
that is installed in their scope in the same way as root coroutines do
469-
(see [CoroutineExceptionHandler](#coroutineexceptionhandler) section for details).
469+
(see the [CoroutineExceptionHandler](#coroutineexceptionhandler) section for details).
470470

471471
<div class="sample" markdown="1" theme="idea" data-highlight-only>
472472

@@ -480,12 +480,12 @@ fun main() = runBlocking {
480480
}
481481
supervisorScope {
482482
val child = launch(handler) {
483-
println("Child throws an exception")
483+
println("The child throws an exception")
484484
throw AssertionError()
485485
}
486-
println("Scope is completing")
486+
println("The scope is completing")
487487
}
488-
println("Scope is completed")
488+
println("The scope is completed")
489489
}
490490
```
491491

@@ -496,10 +496,10 @@ fun main() = runBlocking {
496496
The output of this code is:
497497

498498
```text
499-
Scope is completing
500-
Child throws an exception
499+
The scope is completing
500+
The child throws an exception
501501
CoroutineExceptionHandler got java.lang.AssertionError
502-
Scope is completed
502+
The scope is completed
503503
```
504504
<!--- TEST-->
505505

@@ -517,8 +517,8 @@ Scope is completed
517517
[runBlocking]: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/run-blocking.html
518518
[SupervisorJob()]: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-supervisor-job.html
519519
[Job()]: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-job.html
520-
[supervisorScope]: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/supervisor-scope.html
521520
[coroutineScope]: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/coroutine-scope.html
521+
[supervisorScope]: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/supervisor-scope.html
522522
<!--- INDEX kotlinx.coroutines.channels -->
523523
[actor]: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.channels/actor.html
524524
[produce]: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.channels/produce.html

integration/kotlinx-coroutines-jdk8/src/future/Future.kt

+2-2
Original file line numberDiff line numberDiff line change
@@ -11,10 +11,10 @@ import java.util.function.*
1111
import kotlin.coroutines.*
1212

1313
/**
14-
* Starts new coroutine and returns its result as an implementation of [CompletableFuture].
14+
* Starts a new coroutine and returns its result as an implementation of [CompletableFuture].
1515
* The running coroutine is cancelled when the resulting future is cancelled or otherwise completed.
1616
*
17-
* Coroutine context is inherited from a [CoroutineScope], additional context elements can be specified with [context] argument.
17+
* The coroutine context is inherited from a [CoroutineScope], additional context elements can be specified with the [context] argument.
1818
* If the context does not have any dispatcher nor any other [ContinuationInterceptor], then [Dispatchers.Default] is used.
1919
* The parent job is inherited from a [CoroutineScope] as well, but it can also be overridden
2020
* with corresponding [context] element.

kotlinx-coroutines-core/jvm/test/guide/example-supervision-01.kt

+5-5
Original file line numberDiff line numberDiff line change
@@ -12,24 +12,24 @@ fun main() = runBlocking {
1212
with(CoroutineScope(coroutineContext + supervisor)) {
1313
// launch the first child -- its exception is ignored for this example (don't do this in practice!)
1414
val firstChild = launch(CoroutineExceptionHandler { _, _ -> }) {
15-
println("First child is failing")
16-
throw AssertionError("First child is cancelled")
15+
println("The first child is failing")
16+
throw AssertionError("The first child is cancelled")
1717
}
1818
// launch the second child
1919
val secondChild = launch {
2020
firstChild.join()
2121
// Cancellation of the first child is not propagated to the second child
22-
println("First child is cancelled: ${firstChild.isCancelled}, but second one is still active")
22+
println("The first child is cancelled: ${firstChild.isCancelled}, but the second one is still active")
2323
try {
2424
delay(Long.MAX_VALUE)
2525
} finally {
2626
// But cancellation of the supervisor is propagated
27-
println("Second child is cancelled because supervisor is cancelled")
27+
println("The second child is cancelled because the supervisor was cancelled")
2828
}
2929
}
3030
// wait until the first child fails & completes
3131
firstChild.join()
32-
println("Cancelling supervisor")
32+
println("Cancelling the supervisor")
3333
supervisor.cancel()
3434
secondChild.join()
3535
}

kotlinx-coroutines-core/jvm/test/guide/example-supervision-02.kt

+4-4
Original file line numberDiff line numberDiff line change
@@ -13,18 +13,18 @@ fun main() = runBlocking {
1313
supervisorScope {
1414
val child = launch {
1515
try {
16-
println("Child is sleeping")
16+
println("The child is sleeping")
1717
delay(Long.MAX_VALUE)
1818
} finally {
19-
println("Child is cancelled")
19+
println("The child is cancelled")
2020
}
2121
}
2222
// Give our child a chance to execute and print using yield
2323
yield()
24-
println("Throwing exception from scope")
24+
println("Throwing an exception from the scope")
2525
throw AssertionError()
2626
}
2727
} catch(e: AssertionError) {
28-
println("Caught assertion error")
28+
println("Caught an assertion error")
2929
}
3030
}

kotlinx-coroutines-core/jvm/test/guide/example-supervision-03.kt

+3-3
Original file line numberDiff line numberDiff line change
@@ -14,10 +14,10 @@ fun main() = runBlocking {
1414
}
1515
supervisorScope {
1616
val child = launch(handler) {
17-
println("Child throws an exception")
17+
println("The child throws an exception")
1818
throw AssertionError()
1919
}
20-
println("Scope is completing")
20+
println("The scope is completing")
2121
}
22-
println("Scope is completed")
22+
println("The scope is completed")
2323
}

kotlinx-coroutines-core/jvm/test/guide/test/ExceptionsGuideTest.kt

+11-11
Original file line numberDiff line numberDiff line change
@@ -63,30 +63,30 @@ class ExceptionsGuideTest {
6363
@Test
6464
fun testExampleSupervision01() {
6565
test("ExampleSupervision01") { kotlinx.coroutines.guide.exampleSupervision01.main() }.verifyLines(
66-
"First child is failing",
67-
"First child is cancelled: true, but second one is still active",
68-
"Cancelling supervisor",
69-
"Second child is cancelled because supervisor is cancelled"
66+
"The first child is failing",
67+
"The first child is cancelled: true, but the second one is still active",
68+
"Cancelling the supervisor",
69+
"The second child is cancelled because the supervisor was cancelled"
7070
)
7171
}
7272

7373
@Test
7474
fun testExampleSupervision02() {
7575
test("ExampleSupervision02") { kotlinx.coroutines.guide.exampleSupervision02.main() }.verifyLines(
76-
"Child is sleeping",
77-
"Throwing exception from scope",
78-
"Child is cancelled",
79-
"Caught assertion error"
76+
"The child is sleeping",
77+
"Throwing an exception from the scope",
78+
"The child is cancelled",
79+
"Caught an assertion error"
8080
)
8181
}
8282

8383
@Test
8484
fun testExampleSupervision03() {
8585
test("ExampleSupervision03") { kotlinx.coroutines.guide.exampleSupervision03.main() }.verifyLines(
86-
"Scope is completing",
87-
"Child throws an exception",
86+
"The scope is completing",
87+
"The child throws an exception",
8888
"CoroutineExceptionHandler got java.lang.AssertionError",
89-
"Scope is completed"
89+
"The scope is completed"
9090
)
9191
}
9292
}

reactive/kotlinx-coroutines-reactive/README.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -6,14 +6,14 @@ Coroutine builders:
66

77
| **Name** | **Result** | **Scope** | **Description**
88
| --------------- | ----------------------------- | ---------------- | ---------------
9-
| [publish] | `Publisher` | [ProducerScope] | Cold reactive publisher that starts coroutine on subscribe
9+
| [publish] | `Publisher` | [ProducerScope] | Cold reactive publisher that starts the coroutine on subscribe
1010

1111
Integration with [Flow]:
1212

1313
| **Name** | **Result** | **Description**
1414
| --------------- | -------------- | ---------------
15-
| [Publisher.asFlow] | `Flow` | Converts the given publisher to flow
16-
| [Flow.asPublisher] | `Publisher` | Converts the given flow to the TCK-compliant publisher
15+
| [Publisher.asFlow] | `Flow` | Converts the given publisher to a flow
16+
| [Flow.asPublisher] | `Publisher` | Converts the given flow to a TCK-compliant publisher
1717

1818
If these adapters are used along with `kotlinx-coroutines-reactor` in the classpath, then Reactor's `Context` is properly
1919
propagated as coroutine context element (`ReactorContext`) and vice versa.

reactive/kotlinx-coroutines-reactor/README.md

+10-10
Original file line numberDiff line numberDiff line change
@@ -6,29 +6,29 @@ Coroutine builders:
66

77
| **Name** | **Result** | **Scope** | **Description**
88
| --------------- | ------------| ---------------- | ---------------
9-
| [mono] | `Mono` | [CoroutineScope] | Cold mono that starts coroutine on subscribe
10-
| [flux] | `Flux` | [CoroutineScope] | Cold flux that starts coroutine on subscribe
9+
| [mono] | `Mono` | [CoroutineScope] | A cold Mono that starts the coroutine on subscription
10+
| [flux] | `Flux` | [CoroutineScope] | A cold Flux that starts the coroutine on subscription
1111

12-
Note that `Mono` and `Flux` are a subclass of [Reactive Streams](https://www.reactive-streams.org)
13-
`Publisher` and extensions for it are covered by
12+
Note that `Mono` and `Flux` are subclasses of [Reactive Streams](https://www.reactive-streams.org)'
13+
`Publisher` and extensions for it are covered by the
1414
[kotlinx-coroutines-reactive](../kotlinx-coroutines-reactive) module.
1515

1616
Integration with [Flow]:
1717

1818
| **Name** | **Result** | **Description**
1919
| --------------- | -------------- | ---------------
20-
| [Flow.asFlux] | `Flux` | Converts the given flow to the TCK-compliant Flux.
20+
| [Flow.asFlux] | `Flux` | Converts the given flow to a TCK-compliant Flux.
2121

22-
This adapter is integrated with Reactor's `Context` and coroutines [ReactorContext].
22+
This adapter is integrated with Reactor's `Context` and coroutines' [ReactorContext].
2323

2424
Conversion functions:
2525

2626
| **Name** | **Description**
2727
| -------- | ---------------
28-
| [Job.asMono][kotlinx.coroutines.Job.asMono] | Converts job to hot mono
29-
| [Deferred.asMono][kotlinx.coroutines.Deferred.asMono] | Converts deferred value to hot mono
30-
| [ReceiveChannel.asFlux][kotlinx.coroutines.channels.ReceiveChannel.asFlux] | Converts streaming channel to hot flux
31-
| [Scheduler.asCoroutineDispatcher][reactor.core.scheduler.Scheduler.asCoroutineDispatcher] | Converts scheduler to [CoroutineDispatcher]
28+
| [Job.asMono][kotlinx.coroutines.Job.asMono] | Converts a job to a hot Mono
29+
| [Deferred.asMono][kotlinx.coroutines.Deferred.asMono] | Converts a deferred value to a hot Mono
30+
| [ReceiveChannel.asFlux][kotlinx.coroutines.channels.ReceiveChannel.asFlux] | Converts a streaming channel to a hot Flux
31+
| [Scheduler.asCoroutineDispatcher][reactor.core.scheduler.Scheduler.asCoroutineDispatcher] | Converts a scheduler to a [CoroutineDispatcher]
3232

3333
<!--- MODULE kotlinx-coroutines-core -->
3434
<!--- INDEX kotlinx.coroutines -->

0 commit comments

Comments
 (0)