Exception handling in coroutines in Kotlin - Deep Dive

Overview - Exception handling in coroutines

What is it?

Exception handling in coroutines is the way Kotlin manages errors that happen while running coroutines, which are lightweight threads for asynchronous tasks. It helps catch and respond to problems without crashing the whole program. This system works differently than regular try-catch blocks because coroutines can run in many places at once and may be cancelled or combined.

Why it matters

Without proper exception handling in coroutines, errors could silently fail or crash the entire app unexpectedly, making programs unreliable and hard to debug. Since coroutines are used for tasks like network calls or animations, managing exceptions ensures smooth user experiences and stable apps. It also helps developers write cleaner, safer asynchronous code.

Where it fits

Before learning this, you should understand basic Kotlin syntax, functions, and how coroutines work. After mastering exception handling in coroutines, you can explore advanced coroutine features like structured concurrency, custom CoroutineExceptionHandler, and cancellation mechanisms.

Mental Model

Core Idea

Exception handling in coroutines is about catching errors that happen inside asynchronous tasks and deciding how to respond without stopping unrelated work.

Think of it like...

Imagine a team of chefs working on different dishes in a kitchen. If one chef burns a dish (an error), the kitchen manager (exception handler) decides whether to fix it, replace it, or stop that chef, without shutting down the whole kitchen.

Coroutine Scope
  │
  ├─ Coroutine 1 (try-catch inside)
  │     └─ Handles its own exceptions
  ├─ Coroutine 2 (no try-catch)
  │     └─ Exception propagates to parent
  └─ Coroutine Exception Handler
        └─ Catches uncaught exceptions from children

Build-Up - 7 Steps

1

Foundation

Basics of Kotlin Coroutines

Concept: Introduces what coroutines are and how they run asynchronous code.

Coroutines let you write code that can pause and resume without blocking the main thread. You start a coroutine using builders like launch or async inside a CoroutineScope. They run concurrently but are lightweight compared to threads.

Result

You can run multiple tasks at once without freezing your app.

Understanding coroutines as lightweight threads is key to grasping why exception handling needs special care.

2

Foundation

Simple Try-Catch in Coroutines

Concept: Shows how to catch exceptions inside a coroutine using try-catch blocks.

Inside a coroutine, you can wrap code with try-catch to handle exceptions locally: launch { try { // risky code } catch (e: Exception) { println("Caught: ${e.message}") } } This catches errors only inside that coroutine block.

Result

Exceptions are caught and handled without crashing the coroutine or app.

Local try-catch works like usual but only affects the coroutine it’s in, not others.

3

Intermediate

Exception Propagation in Coroutine Hierarchy

🤔Before reading on: Do you think an exception in a child coroutine always stops its parent coroutine? Commit to your answer.

Concept: Explains how exceptions move up from child coroutines to their parent scopes.

If a child coroutine throws an uncaught exception, it cancels its parent and siblings by default. For example: val parentJob = CoroutineScope(Dispatchers.Default).launch { launch { throw Exception("Error in child") } launch { delay(1000); println("Sibling runs") } } The exception cancels the parent, so siblings may not finish.

Result

Uncaught exceptions in children cancel the whole coroutine scope.

Knowing that exceptions propagate up helps prevent unexpected cancellations in your app.

4

Intermediate

Using CoroutineExceptionHandler

🤔Before reading on: Can CoroutineExceptionHandler catch exceptions from async coroutines? Commit to your answer.

Concept: Introduces CoroutineExceptionHandler to catch uncaught exceptions globally in a coroutine scope.

You can define a handler to catch exceptions not caught by try-catch: val handler = CoroutineExceptionHandler { _, exception -> println("Caught globally: ${exception.message}") } CoroutineScope(Dispatchers.Default + handler).launch { throw Exception("Oops") } Note: It only catches exceptions from launch, not async.

Result

Global exceptions are caught and logged without crashing the app.

Understanding the limits of CoroutineExceptionHandler prevents silent failures in async coroutines.

5

Intermediate

Handling Exceptions in async Coroutines

🤔Before reading on: Do you think exceptions in async coroutines are thrown immediately or only when awaited? Commit to your answer.

Concept: Shows that exceptions in async coroutines are deferred until their result is awaited.

When you use async, exceptions don’t crash immediately: val deferred = CoroutineScope(Dispatchers.Default).async { throw Exception("Async error") } try { deferred.await() } catch (e: Exception) { println("Caught on await: ${e.message}") } The exception is thrown only when await() is called.

Result

You control when to handle async exceptions by awaiting the result.

Knowing this helps avoid unexpected crashes and manage async errors properly.

6

Advanced

Structured Concurrency and Exception Handling

🤔Before reading on: Does structured concurrency guarantee all child coroutines complete even if one fails? Commit to your answer.

Concept: Explains how structured concurrency cancels sibling coroutines on failure to keep code predictable.

In structured concurrency, if one child fails, the parent cancels all children: coroutineScope { launch { delay(1000); println("Child 1 done") } launch { throw Exception("Child 2 fails") } } The exception cancels Child 1 before it finishes. This avoids orphan coroutines running unexpectedly.

Result

Coroutines are managed as a group, improving reliability and cleanup.

Understanding structured concurrency prevents resource leaks and inconsistent states.

7

Expert

Advanced Exception Handling Strategies

🤔Before reading on: Can you recover from a coroutine cancellation exception inside a coroutine? Commit to your answer.

Concept: Covers handling CancellationException, supervisor jobs, and recovery techniques.

CancellationException is special and usually not caught to allow proper cancellation. Using SupervisorJob lets siblings fail independently: val supervisor = SupervisorJob() val scope = CoroutineScope(Dispatchers.Default + supervisor) scope.launch { throw Exception("Fail") } scope.launch { delay(1000); println("Still runs") } You can also catch CancellationException to clean up but should rethrow it to respect cancellation.

Result

You gain fine control over failure isolation and cancellation behavior.

Knowing these advanced tools helps build robust, fault-tolerant coroutine systems.

Under the Hood

Kotlin coroutines run on top of threads but manage their own lifecycle and context. When an exception occurs inside a coroutine, it checks if it is caught locally. If not, it propagates up the coroutine hierarchy, cancelling parent and siblings unless a SupervisorJob is used. CoroutineExceptionHandler intercepts uncaught exceptions from launch coroutines but not from async until awaited. CancellationException signals coroutine cancellation and is treated specially to allow cooperative cancellation.

Why designed this way?

This design balances safety and flexibility. Propagating exceptions up prevents silent failures and resource leaks. Separating launch and async exception handling matches their different usage patterns. SupervisorJob allows independent failure to avoid cascading crashes. The special CancellationException supports cooperative cancellation, a key coroutine feature. Alternatives like global try-catch would be less flexible and error-prone.

┌─────────────────────────────┐
│ Coroutine Scope             │
│  ├─ Coroutine 1 (launch)    │
│  │    └─ try-catch?         │
│  │    └─ throws Exception ─┐│
│  ├─ Coroutine 2 (async)     ││
│  │    └─ exception deferred ││
│  └─ CoroutineExceptionHandler│
└─────────────┬───────────────┘
              │
              ▼
    Exception propagates up
              │
  ┌───────────┴────────────┐
  │ Parent Coroutine Scope  │
  │ Cancels children on fail│
  └────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does CoroutineExceptionHandler catch exceptions from async coroutines automatically? Commit yes or no.

Common Belief: CoroutineExceptionHandler catches all uncaught exceptions in coroutines, including async.

Reality: CoroutineExceptionHandler only catches exceptions from launch coroutines; async exceptions are thrown when awaited.

Why it matters: Assuming it catches async exceptions leads to silent failures or crashes when await is called without try-catch.

Quick: If one child coroutine fails, do all sibling coroutines keep running? Commit yes or no.

Common Belief: Child coroutines run independently; one failing does not affect others.

Reality: By default, one failing child cancels the parent and all siblings unless SupervisorJob is used.

Why it matters: Not knowing this causes unexpected cancellations and lost work in sibling coroutines.

Quick: Can you catch and ignore CancellationException like other exceptions? Commit yes or no.

Common Belief: CancellationException is just another exception and can be caught and ignored safely.

Reality: CancellationException should usually be rethrown to allow proper coroutine cancellation.

Why it matters: Ignoring CancellationException breaks cooperative cancellation, causing coroutines to run longer than intended.

Quick: Does a try-catch block outside a coroutine catch exceptions thrown inside it? Commit yes or no.

Common Belief: A try-catch outside a coroutine can catch exceptions thrown inside the coroutine.

Reality: Exceptions inside coroutines are asynchronous and must be caught inside the coroutine or via handlers; outside try-catch won't catch them.

Why it matters: Misunderstanding this leads to uncaught exceptions and crashes.

Expert Zone

1

SupervisorJob allows sibling coroutines to fail independently, which is crucial for complex concurrent tasks where one failure should not stop others.

2

CancellationException is a control mechanism, not an error; catching it without rethrowing breaks the cancellation contract and can cause resource leaks.

3

CoroutineExceptionHandler only works with launch coroutines because async defers exceptions until await, reflecting different error handling philosophies.

When NOT to use

Avoid using CoroutineExceptionHandler for async coroutines; instead, handle exceptions with try-catch around await. Do not catch CancellationException unless you rethrow it immediately. For fine-grained failure isolation, use SupervisorJob instead of default Job. For simple synchronous error handling, prefer regular try-catch outside coroutines.

Production Patterns

In production, developers use SupervisorJob to isolate failures in concurrent tasks like multiple network calls. They combine CoroutineExceptionHandler for logging uncaught launch exceptions and try-catch around async await calls. CancellationException handling is used to clean up resources on coroutine cancellation. Structured concurrency ensures predictable lifecycle and resource management.

Connections

Structured Concurrency

Builds-on

Exception handling in coroutines relies on structured concurrency to manage cancellation and error propagation predictably.

Reactive Programming

Similar pattern

Both coroutines and reactive streams handle asynchronous errors carefully to avoid crashing the whole system and to allow recovery.

Project Management Risk Handling

Analogous concept

Managing exceptions in coroutines is like managing risks in projects: catching and isolating problems early prevents total project failure.

Common Pitfalls

#1 Assuming CoroutineExceptionHandler catches async coroutine exceptions.

Wrong approach:

val handler = CoroutineExceptionHandler { _, e -> println("Caught: $e") }
CoroutineScope(Dispatchers.Default + handler).async {
throw Exception("Fail")
}
// No await called

Correct approach:

val deferred = CoroutineScope(Dispatchers.Default).async {
throw Exception("Fail")
}
try {
deferred.await()
} catch (e: Exception) {
println("Caught on await: $e")
}

Root cause:

Misunderstanding that async exceptions are deferred until await is called.

#2 Catching CancellationException and ignoring it.

Wrong approach:

launch {
try {
// work
} catch (e: CancellationException) {
println("Ignoring cancellation")
}
}

Correct approach:

launch {
try {
// work
} catch (e: CancellationException) {
println("Cleanup on cancellation")
throw e
}
}

Root cause:

Not realizing CancellationException signals coroutine cancellation and must be rethrown.

#3 Using try-catch outside coroutine to catch coroutine exceptions.

Wrong approach:

try {
CoroutineScope(Dispatchers.Default).launch {
throw Exception("Error")
}
} catch (e: Exception) {
println("Caught")
}

Correct approach:

CoroutineScope(Dispatchers.Default).launch {
try {
throw Exception("Error")
} catch (e: Exception) {
println("Caught")
}
}

Root cause:

Not understanding that coroutine exceptions are asynchronous and must be caught inside coroutine or via handlers.

Key Takeaways

Exception handling in coroutines is essential to manage errors in asynchronous tasks without crashing the whole app.

Local try-catch blocks catch exceptions inside a coroutine, but uncaught exceptions propagate up and can cancel parent and sibling coroutines.

CoroutineExceptionHandler catches uncaught exceptions from launch coroutines but does not catch exceptions from async until their result is awaited.

CancellationException is special and should be rethrown to allow proper coroutine cancellation and resource cleanup.

Using SupervisorJob allows sibling coroutines to fail independently, improving fault tolerance in concurrent systems.

Practice

1. What is the primary way to catch exceptions inside a Kotlin coroutine launched with launch?

easy

A. Use try-catch block inside the coroutine code

B. Use catch method on the coroutine builder

C. Use finally block outside the coroutine

D. Exceptions cannot be caught in coroutines

Solution

1. Step 1: Understand coroutine exception handling basics

   Exceptions inside launch coroutines are caught by try-catch blocks within the coroutine code itself.

2. Step 2: Identify correct method to catch exceptions

   The catch method does not exist on coroutine builders, and finally outside coroutine does not catch coroutine exceptions.

3. Final Answer:

   Use try-catch block inside the coroutine code -> Option A

4. Quick Check:

   try-catch inside coroutine = correct way [OK]

Hint: Catch exceptions inside coroutine with try-catch [OK]

Common Mistakes:

• Thinking catch method exists on coroutine builders
• Using finally block outside coroutine to catch exceptions
• Assuming exceptions cannot be caught in coroutines

2. Which of the following is the correct syntax to define a CoroutineExceptionHandler in Kotlin?

easy

A. val handler = CoroutineExceptionHandler { println(exception) }

B. val handler = CoroutineExceptionHandler { exception -> println(exception) }

C. val handler = CoroutineExceptionHandler(context, exception -> println(exception))

D. val handler = CoroutineExceptionHandler { context, exception -> println(exception) }

Solution

1. Step 1: Recall CoroutineExceptionHandler signature

   It takes a lambda with two parameters: context and exception.

2. Step 2: Match correct syntax

   val handler = CoroutineExceptionHandler { context, exception -> println(exception) } correctly uses the two parameters in the lambda. Other options miss parameters or have wrong syntax.

3. Final Answer:

   val handler = CoroutineExceptionHandler { context, exception -> println(exception) } -> Option D

4. Quick Check:

   CoroutineExceptionHandler requires (context, exception) lambda [OK]

Hint: CoroutineExceptionHandler lambda needs context and exception [OK]

Common Mistakes:

• Omitting context parameter in lambda
• Passing parameters incorrectly
• Using invalid constructor syntax

3. What will be the output of the following Kotlin code?

import kotlinx.coroutines.*

fun main() = runBlocking {
    val handler = CoroutineExceptionHandler { _, exception ->
        println("Caught: ${exception.message}")
    }
    val job = launch(handler) {
        throw IllegalArgumentException("Invalid argument")
    }
    job.join()
    println("Done")
}

medium

A. Caught: Invalid argument
Done

B. Exception in thread "main" java.lang.IllegalArgumentException: Invalid argument

C. Done

D. Caught: null
Done

Solution

1. Step 1: Understand CoroutineExceptionHandler usage

   The handler catches exceptions thrown inside the launch coroutine and prints the message.

2. Step 2: Trace program output

   The exception message "Invalid argument" is printed by the handler, then "Done" is printed after job.join().

3. Final Answer:

   Caught: Invalid argument Done -> Option A

4. Quick Check:

   Exception caught by handler, then Done printed [OK]

Hint: ExceptionHandler prints message, then main continues [OK]

Common Mistakes:

• Expecting uncaught exception crash
• Missing that handler catches exception
• Ignoring job.join() effect

4. Identify the error in this Kotlin coroutine exception handling code:

import kotlinx.coroutines.*

fun main() = runBlocking {
    val handler = CoroutineExceptionHandler { _, exception ->
        println("Error: ${exception.message}")
    }
    val job = async(handler) {
        throw RuntimeException("Failure")
    }
    job.await()
}

medium

A. Missing try-catch block inside async coroutine

B. The handler lambda parameters are incorrect

C. CoroutineExceptionHandler does not catch exceptions from async coroutines

D. Using runBlocking incorrectly

Solution

1. Step 1: Understand exception handling difference between launch and async

   Exceptions in async are propagated via the deferred result and must be caught by try-catch on await().

2. Step 2: Analyze why CoroutineExceptionHandler fails here

   CoroutineExceptionHandler does not catch exceptions from async coroutines because they are deferred until await().

3. Final Answer:

   CoroutineExceptionHandler does not catch exceptions from async coroutines -> Option C

4. Quick Check:

   async exceptions need try-catch on await() [OK]

Hint: Use try-catch on await() for async exceptions [OK]

Common Mistakes:

• Expecting CoroutineExceptionHandler to catch async exceptions
• Ignoring need for try-catch on await()
• Misunderstanding handler lambda parameters

5. You want to handle exceptions from multiple launch coroutines in a Kotlin app and log errors without stopping other coroutines. Which approach is best?

hard

A. Use async coroutines and catch exceptions on await()

B. Attach a shared CoroutineExceptionHandler to the parent scope and launch coroutines within it

C. Wrap each coroutine body in a try-catch block and ignore exceptions

D. Use SupervisorJob without any exception handling

Solution

1. Step 1: Understand exception handling for multiple launch coroutines

   Using a shared CoroutineExceptionHandler on the parent scope catches exceptions from all child launch coroutines without cancelling siblings.

2. Step 2: Evaluate other options

   Wrapping each coroutine in try-catch is verbose and error-prone; async with await is for deferred results; SupervisorJob alone does not handle exceptions or logging.

3. Final Answer:

   Attach a shared CoroutineExceptionHandler to the parent scope and launch coroutines within it -> Option B

4. Quick Check:

   Shared handler on parent scope manages launch exceptions [OK]

Hint: Use shared CoroutineExceptionHandler on parent for launch coroutines [OK]

Common Mistakes:

• Ignoring shared handler benefits
• Using async instead of launch for fire-and-forget
• Not handling exceptions leads to crashes