skip to content

When would you choose withContext over async { }.await() for running work on another dispatcher?

level: middleimportance: must knowfreq 65%

answer

  1. Single offload = withContext; parallel = async/await
  2. async allocates a Deferred, withContext does not
  3. withContext throws at call site, async throws at await()
  4. async+immediate await is a pointless heavier withContext
  5. Concurrency needs multiple async started before awaiting

basics

~10 s

Use withContext when you just need to run one block somewhere else and get its result in sequence. Use async/await only when you want two or more things running at the same time.

solid answer

~40 s

For a single sequential offload, prefer withContext(dispatcher) { ... }: it is cheaper (no extra Deferred/coroutine object), reads top-to-bottom, and propagates exceptions directly at the call site. async(dispatcher) { ... }.await() does the same logically but creates a child coroutine you must await; its real value is concurrency — start multiple async blocks, then await them so they overlap. A subtle exception difference: with withContext an exception surfaces synchronously where you call it; with async the exception is stored in the Deferred and thrown at await() (and in a coroutineScope it can also cancel siblings). Rule of thumb: 'one thing, then continue' → withContext; 'several things at once' → multiple async + await, usually wrapped in coroutineScope.

go deeper

for a junior

Knows withContext is for one block and async is for parallelism.

for a middle

Articulates the cost/allocation difference and the sequential-vs-concurrent rule clearly.

for a senior

Explains the exception-timing difference and how structured concurrency affects sibling cancellation.

for a principal

Reasons about API ergonomics and when to expose concurrency via coroutineScope to callers vs hide it.

## The two shapes ```kotlin // Sequential offload — idiomatic val user = withContext(Dispatchers.IO) { repo.load(id) } // Concurrent fan-out — async is the right tool coroutineScope { val a = async(Dispatchers.IO) { repo.loadA() } val b = async(Dispatchers.IO) { repo.loadB() } combine(a.await(), b.await()) // a and b run in parallel } ``` ## Why `withContext` for a single block - **Cheaper**: `async` allocates a `Deferred<T>` (a `Job`) and registers a child coroutine; `withContext` reuses the current coroutine and only swaps context. - **Reads sequentially**: the result is returned directly — no dangling `Deferred` to remember to `await`. - **No accidental concurrency**: `async` without `await` can leave work running unexpectedly; `withContext` cannot. ## Exception handling difference - `withContext` throws the block's exception **synchronously at the call site**. - `async` **stores** the exception in the `Deferred`; it is thrown when you call `await()`. If you forget to await, the exception can be lost (though structured concurrency still propagates it to the parent scope, possibly cancelling siblings). ## When `async` actually wins Only when you want **overlap**: launch several `async` blocks, let them run concurrently, then `await` each. Doing the same with sequential `withContext` calls would run them one after another, losing the speedup. ## Anti-pattern ```kotlin // Pointless: async + immediate await = sequential, but heavier val x = async(Dispatchers.IO) { f() }.await() // Prefer: val x = withContext(Dispatchers.IO) { f() } ``` ## Recap - One sequential offload → `withContext`. - Concurrent work → multiple `async` + `await`, wrapped in `coroutineScope`/`supervisorScope`.

  • Show the wrong way to get parallelism with withContext and why it fails.
    Two back-to-back withContext calls run sequentially — the second only starts after the first returns, so there is no overlap. You need two async blocks started before awaiting.
  • Where does an exception from the block surface for withContext vs async?
    withContext rethrows synchronously at the call site; async stores it in the Deferred and rethrows it at await().

saying these in an interview costs you the question

  • Claiming async { }.await() is more efficient than withContext for one block
  • Using sequential withContext calls and expecting parallel execution
  • Not knowing async defers its exception to await()
  • Saying withContext can run two blocks concurrently

context

resolving links…