Отмена и сбои корутин

Отмена в корутинах устроена принципиально иначе, чем прерывание потока: это не силовое выдёргивание из выполняемого кода, а кооперативный протокол. Вызывая cancel(), вы не останавливаете корутину — вы переводите её Job в отменённое состояние и полагаетесь на то, что код сам заметит это в ближайшей точке приостановки. Все suspend-функции из kotlinx.coroutines при возобновлении бросают CancellationException; но плотный CPU-цикл без единой приостановки не заметит отмену вовсе и честно досчитает до конца, уже будучи отменённым. Отсюда — половина ловушек темы.

Вторая половина растёт из того, что отмена и сбой распространяются по дереву Job. Отмена идёт вниз, к детям, а сбой ребёнка идёт ещё и вверх, отменяя родителя и вместе с ним всех братьев — это следствие структурной конкурентности, где родитель ждёт всех детей и отвечает за их сбои. SupervisorJob разрывает путь вверх, оставляя изоляцию; CoroutineExceptionHandler ловит то, что не поймали внутри. И над всем этим — особый статус CancellationException: это не ошибка, а сам механизм отмены, поэтому широкий catch или runCatching, проглотив его, тихо ломают отмену, а finally в отменённой корутине не может сделать ни одного suspend-вызова без NonCancellable. Разбор по слоям — ниже.

Карта темы

• Иерархия Job — Job как ручка жизненного цикла и узел дерева, его состояния, распространение отмены вниз и сбоя вверх, и ловушка подменённого Job, рвущего дерево.
• Кооперативная отмена — почему cancel() лишь ставит флаг, как suspend-точки бросают при возобновлении и чем yield(), ensureActive() и isActive делают ваш цикл отменяемым.
• Безопасная при отмене очистка — почему CancellationException нельзя глотать, почему suspend-вызов в finally падает сразу и зачем нужен withContext(NonCancellable).
• SupervisorJob и изоляция сбоев — обычный Job кладёт всех братьев, SupervisorJob пускает сбой только вниз, и две ловушки: тело supervisorScope всё равно бросает при await(), а супервизор должен быть прямым родителем.
• CoroutineExceptionHandler — последний рубеж, работающий только на корне scope, срабатывающий для launch, но не для async, и не ловящий отмену.

Частые ошибки и ловушки

Значение для собеседований

Отмена корутин — раздел, где интервьюер проверяет не словарь, а модель исполнения. Один вопрос отделяет заучившего от понимающего: «что физически делает cancel()?». Правильный ответ — не «останавливает корутину», а «переводит Job в отменённое состояние и резюмирует точки приостановки исключением; тело останавливается там, где оно приостанавливается или спрашивает о своём состоянии». Из этой одной модели выводится всё: почему CPU-цикл игнорирует отмену, почему catch (e: Exception) её ломает, почему finally не может закрыть ресурс без NonCancellable и почему сбой одного виджета кладёт весь экран.

Что обычно проверяют:

• Что происходит с детьми при отмене Job и почему родитель ждёт их завершения.
• Почему отмена кооперативна и как сделать плотный цикл отменяемым (yield / ensureActive / isActive).
• Почему CancellationException особое и что случится, если поймать его широким catch.
• Как выполнить suspend-очистку в отменённой корутине и какие пределы у NonCancellable.
• Чем SupervisorJob и supervisorScope меняют распространение сбоя и где их ставить.
• На какой корутине срабатывает CoroutineExceptionHandler и почему async его не зовёт.

Типичный неверный ответ: «cancel() немедленно останавливает корутину, где бы она ни была». Из этой ошибки растёт целая гроздь следующих: раз останавливает силой, то CPU-цикл прервётся сам, finally можно писать как угодно, а catch (e: Exception) безопасен. На деле cancel() лишь ставит флаг и резюмирует приостановки исключением; цикл без приостановок доработает до конца, suspend-вызов в finally упадёт сразу, а проглоченный CancellationException оставит корутину живой, и родитель зависнет, ожидая её. Вся тема — про то, где именно и как именно отмена «приземляется».