Как изолировать ошибки в дочерних корутинах от родительской корутины

Изоляция ошибок в дочерних корутинах

Изоляция ошибок между родительской и дочерними корутинами — критически важная задача для создания стабильных и отказоустойчивых асинхронных приложений на Kotlin. По умолчанию иерархическая отмена и структурированный параллелизм в корутинах обеспечивают тесную связь между родительскими и дочерними корутинами. Когда дочерняя корутина падает с исключением, оно по умолчанию распространяется на родителя, приводя к отмене всей иерархии.

Ключевые подходы к изоляции

1. SupervisorJob и SupervisorScope

Основной механизм изоляции — использование SupervisorJob. В отличие от обычного Job, SupervisorJob не отменяет родительскую корутину при падении дочерней.

import kotlinx.coroutines.*

fun main() = runBlocking {
    val supervisor = SupervisorJob()
    val scope = CoroutineScope(coroutineContext + supervisor)
    
    scope.launch {
        delay(100)
        throw RuntimeException("Ошибка в корутине 1")
    }
    
    scope.launch {
        delay(200)
        println("Корутина 2 выполняется, несмотря на ошибку в корутине 1")
    }
    
    delay(300)
    println("Родительская корутина продолжает работу")
}

Более удобный способ — supervisorScope:

suspend fun isolatedOperations() = supervisorScope {
    launch {
        // Эта корутина может упасть без влияния на другие
        mightFail()
    }
    
    launch {
        // Эта корутина продолжит работу даже если первая упадет
        processData()
    }
}

2. Обработка исключений в async/await

При использовании async с SupervisorJob исключения не выбрасываются немедленно, а откладываются до вызова await():

suspend fun processWithIsolation(): List<Result> = supervisorScope {
    val deferred1 = async {
        // Может упасть, но не повлияет на deferred2
        fetchDataFromSource1()
    }
    
    val deferred2 = async {
        fetchDataFromSource2()
    }
    
    // Обрабатываем каждую Deferred отдельно
    val results = mutableListOf<Result>()
    
    try {
        results.add(deferred1.await())
    } catch (e: Exception) {
        println("Ошибка в deferred1: ${e.message}")
    }
    
    try {
        results.add(deferred2.await())
    } catch (e: Exception) {
        println("Ошибка в deferred2: ${e.message}")
    }
    
    results
}

3. CoroutineExceptionHandler с SupervisorJob

Для глобальной обработки ошибок в изолированных корутинах:

val exceptionHandler = CoroutineExceptionHandler { _, throwable ->
    println("Поймано исключение в изолированной корутине: ${throwable.message}")
    // Логирование, уведомление, но не отмена родителя
}

fun startIsolatedWork() {
    val scope = CoroutineScope(SupervisorJob() + Dispatchers.Default + exceptionHandler)
    
    scope.launch {
        // Эта ошибка будет обработана в exceptionHandler
        // и не повлияет на другие корутины
        throw IllegalStateException("Критическая ошибка")
    }
    
    scope.launch {
        // Эта корутина продолжит выполнение
        repeat(10) {
            delay(100)
            println("Работа продолжается...")
        }
    }
}

Практические паттерны изоляции

Паттерн "Обработчик с откатом"

suspend fun <T> isolatedOperation(
    block: suspend () -> T,
    fallback: suspend (Throwable) -> T
): T = supervisorScope {
    try {
        block()
    } catch (e: Exception) {
        fallback(e)
    }
}

// Использование
val result = isolatedOperation(
    block = { riskyOperation() },
    fallback = { error -> 
        println("Операция не удалась: ${error.message}")
        getDefaultValue() 
    }
)

Паттерн "Ограниченный параллелизм с изоляцией"

suspend fun processBatchIsolated(items: List<Data>) = supervisorScope {
    items.map { item ->
        async {
            try {
                processItem(item)
                Result.Success(item)
            } catch (e: Exception) {
                Result.Failure(item, e)
            }
        }
    }.awaitAll()
}

Важные нюансы и рекомендации

• SupervisorJob не предотвращает отмену дочерних корутин при отмене родителя — только изолирует ошибки в обратном направлении
• Исключения в корутинах, запущенных в supervisorScope, все равно нужно обрабатывать, иначе они могут привести к краху всего приложения
• Для глобальной изоляции используйте отдельные CoroutineScope с SupervisorJob для независимых функциональных блоков
• Всегда предусматривайте мониторинг и логирование ошибок в изолированных корутинах, чтобы не потерять информацию о проблемах
• Изоляция не отменяет необходимость правильной отмены ресурсов — используйте try-finally или функции типа use для ресурсов

Антипаттерны

1. Создание корутин без обработки исключений в SupervisorScope
2. Игнорирование всех ошибок без логирования и анализа
3. Излишняя изоляция, когда требуется скоординированное выполнение

Правильная изоляция ошибок позволяет создавать более устойчивые приложения, где сбой одного компонента не приводит к остановке всей системы, при этом сохраняя преимущества структурированного параллелизма.