`launch` starts a child coroutine for work that has no result value to return. Use it for start-and-forget work: the caller continues, while the child can suspend and let other coroutines use the thread. It is a coroutine builder from `kotlinx.coroutines`, rather than the Kotlin standard library. section 14.6 section 14.6.2
Start two child coroutines
```kotlin fun main() = runBlocking { log("Parent starts") launch { log("Delayed child starts") delay(100.milliseconds) log("Delayed child resumes") } launch { log("Other child runs meanwhile") } log("Parent launched children") } ``` `runBlocking` creates the parent coroutine. Each `launch` creates a child. When the delayed child reaches `delay`, it suspends rather than blocking the `main` thread, so the other child can run; it resumes after the delay. section 14.6.1 section 14.6.2
Figure 14.8 The first (parent) coroutine starts and launches two more coroutines. Coroutine 2 executes until its suspension point. It gets suspended without blocking the main thread, freeing it up for coroutine 3 to do its work, before resuming and finishing its execution.
The timeline shows one thread alternating between parent and children: a suspended child frees the thread until it can resume. section 14.6.2
`launch` is an extension on `CoroutineScope`. Launching inside another builder therefore establishes a parent-child relationship automatically. Even if the parent body reaches its end, structured concurrency keeps `runBlocking` alive until its launched children and descendants finish; no manual tracking or awaiting is needed. section 15.1
Treat launched work as part of its coroutine hierarchy:
- Handle an exception inside the `launch` block when that coroutine should recover locally. A `try-catch` around the `launch` call cannot catch an exception thrown later in its new coroutine. section 18.1
- Expect an uncaught child exception to propagate to its parent. With ordinary nonsupervisor coroutines, that failure cancels sibling coroutines as well. section 18.2.1
- Use a `CoroutineExceptionHandler` for uncaught exceptions only when the hierarchy’s topmost coroutine was created with `launch`; a topmost `async` instead leaves handling to `await`. section 18.3.1
Choose `launch` when completion matters structurally but no computed value is needed. Choose `async` when a consumer needs a value through `await`; unlike `launch`, `async` represents that result as a `Deferred`. section 14.6 section 18.1
