What is the difference between coroutineScope and supervisorScope when one of their child coroutines throws an exception?

## The two scope builders Both `coroutineScope` and `supervisorScope` are **suspending functions** that create a new coroutine scope, run the supplied block, and **suspend until all child coroutines launched inside complete**. They are the building blocks of *structured concurrency*: no coroutine started inside escapes the call. The difference is entirely in **how a child failure propagates**. ## coroutineScope — failure cancels everyone `coroutineScope` installs a regular `Job` as the parent of the children launched inside it. The propagation rule for a regular Job is: - When a child throws an uncaught exception (anything that is **not** a `CancellationException`), the failure travels **up** to the parent Job. - The parent then **cancels all of its other children** (siblings of the failing one). - The original exception is **rethrown** from the `coroutineScope { ... }` expression, so the caller can `try/catch` it in one place. ```kotlin suspend fun load() { coroutineScope { launch { throw IllegalStateException("boom") } // fails launch { delay(10_000); println("never prints") } // cancelled } } // the IllegalStateException is rethrown from coroutineScope ``` ## supervisorScope — failures are isolated `supervisorScope` installs a `SupervisorJob` as the parent. A `SupervisorJob` **does not propagate child failures upward**: - A failing child does **not** cancel its siblings. - The failure is **not** rethrown from `supervisorScope` (the scope only rethrows if **its own body** throws directly). - You must handle each child's failure where it is started. ```kotlin supervisorScope { launch { try { riskyWork() } catch (e: Exception) { recover(e) } } launch { otherWork() } // keeps running even if the first fails } ``` ## launch vs async inside these scopes - `launch` exposes failures **eagerly**: an uncaught exception propagates immediately per the rules above. - `async` **defers** the exception: it is stored in the resulting `Deferred` and re-thrown only when you call `await()`. In a `coroutineScope`, an `async` child that fails still cancels the scope (the parent Job sees the failure), but you observe the exception at `await()`. In a `supervisorScope`, a failing `async` is isolated — you must `try/catch` the `await()`. ## CancellationException is special Cancellation is **cooperative and structured**: throwing `CancellationException` cancels only the current coroutine and is treated as normal completion by the parent — it does **not** cancel siblings and is not reported as a failure. This is why catching a broad `Exception` and swallowing it can break cancellation; rethrow `CancellationException`. ## CoroutineExceptionHandler A `CoroutineExceptionHandler` is only invoked for **uncaught** exceptions in **root** coroutines launched with `launch` (it is ignored on `async` and on child coroutines whose parent handles the failure). It is commonly paired with `supervisorScope`/`SupervisorJob` to log uncaught child failures. ## Summary table - coroutineScope → regular Job → child failure cancels siblings + rethrows. - supervisorScope → SupervisorJob → child failure isolated, handle locally. - Both → wait for all children (structured), both honor CancellationException semantics.