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.