Lectures

We unpack structured concurrency in Kotlin coroutines: why coroutines need an “owner” in the form of CoroutineScope, how runBlocking and coroutineScope create operation boundaries and automatically wait for child tasks, what exactly launch returns (a Job), and how to explicitly control wait points via join(). We reinforce the “parent → children” hierarchy idea and assemble a small report from parallel steps in an Expense Tracker example.

We break down how, inside a single coroutine, you can locally switch the execution context using withContext: what CoroutineContext and CoroutineDispatcher are, how Dispatchers. Default (CPU) and Dispatchers. IO (I/O) differ, why withContext is suspend, and why it does not provide parallelism. Using a mini-app (“cash register”) and thread logging as an example, we show switching, practical patterns, and common mistakes.

Let’s break down how cancellation works in kotlinx.coroutines: what the differences are between cancel(), join(), and cancelAndJoin(), why coroutine cancellation is cooperative, where the “suspension points” (for example, delay()) are, and how to write your own loops so they respect cancellation via isActive. At the end, we’ll walk through a practical scenario with a “long report” and review common mistakes.

Let’s break down how exceptions behave in Kotlin coroutines and why error handling differs for launch and async: where try/ catch actually triggers, why an exception from async usually surfaces at await(), how errors “bubble up” at the coroutineScope/ runBlocking boundary, and which common pitfalls (forgotten await(), wrong builder choice, “swallowing” errors) most often break scenarios.

We break down why cleanup in coroutines is part of the contract: a coroutine may finish early due to cancel(), an exception, or an early return. We learn how to guarantee “cleanup” via try/ finally, correctly wait for completion with cancelAndJoin(), distribute responsibility by levels (parent/children), and avoid turning finally into a source of new errors.