Mark Murphy

Note that the inverse is not true: canceling a child job does not cancel its parent.

If the code in a coroutine has an unhandled exception, its job gets canceled

Here, we have two independent jobs. The second job generates a NullPointerException, so it will be canceled at that point, skipping the rest of its work. The first job, though, is unaffected, since it is not related to the second job.

In reality, what happens is that an unhandled exception cancels the parent job, which in turn cancels any children.

Klassbook)
This time, rather than the child canceling the parent directly, the child crashes with a NullPointerException. However, the effect is more or less the same as if the child job had canceled the parent: the parent job is canceled, which in turn cancels the child job.

Sometimes, we need to stop long-running work because it is running too long.

For that, we can use withTimeout(). withTimeout() creates a child job, and it cancels that job if it takes too long.

withTimeout() throws a TimeoutCancellationException. That exception gets handled inside of launch() by default. Since cancellation is considered a normal thing to do, the TimeoutCancellationException does not trigger a crash. However, since withTimeout() threw an exception, the rest of our code inside of launch() gets skipped.

Another variation on withTimeout() is withTimeoutOrNull(). This will return either:

The result of the lambda expression, if it completes before the timeout
null, if the work took too long

Similarly, coroutines are cooperative with respect to cancellation. It is entirely possible to create a coroutine that is oblivious to a cancellation request, but that is not a particularly good idea.

yield() does two things:

Since it is a suspend function, it signals to the coroutines system that it is safe to switch to another coroutine from this dispatcher, if there is one around that is ready to run
It throws CancellationException if the job was canceled