Coroutine Exceptions & Cancellation

Reviewed & published by Brayan K

Structured concurrency makes errors and cancellation predictable — but only if you know the rules. Exceptions propagate differently in launch and async, and cancellation is cooperative.

Part of the free Kotlin course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

By the end you'll handle failures with CoroutineExceptionHandler and supervisorScope, and write cancellation-aware code.

What You'll Learn in This Lesson

• Exception propagation in launch vs async/await
• CoroutineExceptionHandler
• SupervisorJob and supervisorScope
• try/catch inside coroutines
• Cooperative cancellation (isActive, ensureActive, yield)
• Handling CancellationException and NonCancellable cleanup

1️⃣ Exception Propagation: launch vs async

launch propagates exceptions eagerly to its parent; a CoroutineExceptionHandler is the last resort. async defers its exception until you call await(), so you wrap that in try/catch.

import kotlinx.coroutines.*

fun main() = runBlocking {
    // launch PROPAGATES exceptions eagerly to its parent.
    // Handle them with try/catch inside, or a CoroutineExceptionHandler.
    val handler = CoroutineExceptionHandler { _, e ->
        println("Caught in handler: ${e.message}")
    }

    val scope = CoroutineScope(SupervisorJob() + handler)
    scope.launch {
        throw RuntimeException("boom")
    }.join()

    // async DEFERS its exception: it is re-thrown at await().
    val deferred = async { throw IllegalStateException("bad state") }
    try {
        deferred.await()
    } catch (e: IllegalStateException) {
        println("Caught from await: ${e.message}")
    }
}

A handler catches uncaught launch failures; async failures appear at await().

2️⃣ Isolating Failures with supervisorScope

With a regular Job, one failing child cancels its siblings. A SupervisorJob or supervisorScope isolates failures so the rest keep running.

import kotlinx.coroutines.*

fun main() = runBlocking {
    // supervisorScope: one child failing does NOT cancel its siblings.
    supervisorScope {
        val ok = launch {
            delay(50)
            println("Sibling finished successfully")
        }
        val bad = launch {
            // Handle locally so it does not reach the handler.
            try {
                throw RuntimeException("child failed")
            } catch (e: RuntimeException) {
                println("Handled: ${e.message}")
            }
        }
        ok.join(); bad.join()
    }
    println("supervisorScope done")
}

The failing child is handled locally, and its sibling completes unaffected.

3️⃣ Cooperative Cancellation

Cancellation throws a CancellationException at the next suspension point. Cooperate by checking isActive, never swallow that exception, and use withContext(NonCancellable) for essential cleanup.

import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch(Dispatchers.Default) {
        try {
            var i = 0
            // Cooperative cancellation: check isActive (or call ensureActive/yield).
            while (isActive) {
                println("working ${i++}")
                delay(100)   // delay() also throws CancellationException when cancelled
            }
        } catch (e: CancellationException) {
            // DON'T swallow it — rethrow so cancellation completes.
            println("cancelled, cleaning up")
            throw e
        } finally {
            // Essential cleanup that must run even during cancellation:
            withContext(NonCancellable) {
                delay(20)
                println("cleanup done")
            }
        }
    }

    delay(250)
    job.cancelAndJoin()
    println("main: job cancelled")
}

Your turn. Replace the TODOs, then run and compare.

// 🎯 YOUR TURN — replace each TODO.
import kotlinx.coroutines.*

fun main() = runBlocking {
    val job = launch(Dispatchers.Default) {
        // 1) Loop only while the coroutine is still active.
        while (TODO) {                 // 👉 isActive
            // pretend to do work
            delay(50)
        }
    }
    delay(200)

    // 2) Cancel the job and wait for it to finish unwinding.
    job.TODO()                          // 👉 cancelAndJoin()
    println("done")
}

Mini-Challenge: Robust Parallel Loads

Run two async loads in a supervisorScope so one failing doesn't stop the other.

// 🎯 MINI-CHALLENGE: robust parallel loads.
//
// 1. In a supervisorScope, start TWO async loads:
//    - loadA() that succeeds and returns "A"
//    - loadB() that throws RuntimeException("B failed")
// 2. await() each inside its OWN try/catch so B's failure
//    does not stop A.
// 3. Print whichever results succeeded, e.g. "Got: A".
//
// Remember: rethrow CancellationException if you catch a broad type.

import kotlinx.coroutines.*

fun main() = runBlocking {
    // your code here
}

Common Errors (and the fix)

• Swallowing CancellationException — Rethrow it; otherwise the coroutine never actually cancels.
• Expecting a handler to catch async errors — Those surface at await(); wrap it in try/catch.
• Tight loops that ignore cancellation — Check isActive or call ensureActive()/yield().
• Suspending in cleanup after cancellation — Wrap it in withContext(NonCancellable).

Pro Tips

• 💡 Catch specific exceptions rather than a broad Exception so CancellationException still propagates.
• 💡 Use supervisorScope when independent tasks shouldn't take each other down.
• 💡 Built-in suspend functions like delay() already check cancellation for you.

📋 Quick Reference — Errors & Cancellation

🎉 Lesson Complete!

• ✅ launch propagates eagerly; async defers to await()
• ✅ CoroutineExceptionHandler is a last resort for launch failures
• ✅ SupervisorJob/supervisorScope isolate child failures
• ✅ Cancellation is cooperative — check isActive
• ✅ Never swallow CancellationException; clean up with NonCancellable

Practice quiz

Continue this course

• Previous: Gradle & the Kotlin Build System
• Next: KSP & Annotation Processing — Compile-time codegen with Kotlin Symbol Processing — the engine behind Room and Hilt
• Quick reference: Kotlin cheat sheet

Frequently asked questions

Why do launch and async handle exceptions so differently?

They model different intents. launch is fire-and-forget, so an exception has nowhere to be returned — it propagates immediately up to the parent and, if unhandled, reaches a CoroutineExceptionHandler or crashes. async produces a result via a Deferred, so its exception is stored and re-thrown when you call await(). The practical rule: for launch, catch inside the coroutine or install a CoroutineExceptionHandler; for async, wrap the await() call in try/catch. A handler does not catch async/await exceptions — those surface at await.

What is structured concurrency doing when one child fails?

By default, coroutines use a regular Job: if one child throws, it cancels its parent, which in turn cancels all the sibling coroutines — failure tears down the whole scope. That's often what you want, but sometimes one failure shouldn't doom the rest. A SupervisorJob (or a supervisorScope block) changes the policy so a failing child is isolated and its siblings keep running. You still handle the failing child's exception (locally or via a handler), but it no longer cancels everything around it.

How does cancellation actually work, and why is it cooperative?

Cancelling a coroutine doesn't forcibly kill a thread. Instead, the coroutine is marked cancelled and the next suspension point throws a CancellationException, letting it unwind cleanly. This is 'cooperative': your code must reach a suspension point or check for cancellation for it to take effect. In tight CPU loops there may be no suspension, so you cooperate explicitly by checking isActive, calling ensureActive(), or yield(). Built-in suspend functions like delay() already check cancellation for you.

What should I never do with CancellationException, and how do I run cleanup?

Never swallow a CancellationException. It's the very signal that drives cancellation, so catching it and continuing breaks structured concurrency — the coroutine won't actually cancel. If you catch a broad Exception, re-throw it when it's a CancellationException (or catch more specific types instead). For cleanup, a finally block runs during cancellation, but a cancelled coroutine can't suspend normally — so if your cleanup needs to call suspend functions, wrap it in withContext(NonCancellable) so that essential work (closing resources, flushing logs) completes even as the coroutine is being torn down.