Coroutine Exception Handling: launch vs. async

Why it exists

Structured concurrency needs a clear way to handle errors. Without it, an error in one concurrent task could silently fail or bring down the whole system unpredictably. Coroutine exception handling provides clear, predictable rules for how errors propagate and are contained.

The mental model

Think of coroutine builders in two flavors. launch is 'eager' with exceptions: it propagates them immediately, treating them like uncaught thread exceptions. async is 'lazy': it catches its own exceptions and stores them in the Deferred result, waiting for you to call await inside a try/catch block. It's the difference between 'crash now' and 'handle later'.

How it works

When a launch coroutine fails, the exception travels up the job hierarchy. If it reaches the root of the coroutine scope and is unhandled, it will crash the application. In contrast, an exception inside an async block is caught and stored within its Deferred object. The program only becomes aware of the exception when await() is called, which will re-throw it. This allows the caller to handle it in a standard try/catch block.

For uncaught exceptions from launch, you can install a CoroutineExceptionHandler in the coroutine's context. This acts as a last-resort safety net, similar to Thread.uncaughtExceptionHandler. It's for logging or cleanup, not for recovering the failed coroutine, which is already complete when the handler is called.

When to use it

Use launch for fire-and-forget operations where an exception should be a critical, visible failure that needs to be logged globally. Use async when you are computing a value that might fail, and the calling code needs to decide how to handle that failure, for example by providing a default value or retrying.

When not to use it

Do not attach a CoroutineExceptionHandler to an async block; it will have no effect because async always catches its own exceptions. Also, do not install an exception handler on a child coroutine expecting it to catch its own exceptions; children always delegate exception handling to their parent.

One canonical example

A root launch coroutine throwing an IndexOutOfBoundsException will immediately propagate the exception, which is then handled by the thread's uncaught exception handler. A root async coroutine throwing an ArithmeticException will do nothing until deferred.await() is called within a try/catch block, at which point the exception is caught and handled by the caller.