Добрый день! Я сейчас разрабатываю кодогенерацию Swagger для kotlin-multiplatform. Под капотом использую ktor, kotlinx-serialization и kotlinx-coroutines. Одна из фич кодогенерации - обработка схемы кастомных ошибок. Сейчас это реализовано через Exceptions. Это накладывает кучу ограничений. Например, мне всегда нужно пользоваться SupervisorScope и при обработке всегда прокидывать CancellationsException. Насколко я понимаю, exceptions имеют другое значение при использовании корутин (механизм управления ресурасами?). Я попробовал использовать Result из Kotlin 1.3, но его нельзя вернуть и нельзя параметризовать типом ошибки. У каждого роута у меня свой набор ошибок. Мой вопрос в том, как правильно организовать обработку ошибок при использовании корутин (и ktor)?

Не кидать ошибку, вернуть какой нибудь Sealed класс результата, в общем работа с ошибками в этом случае ничем у корутин не отличается с любым другим кодом

Исключения имеют ровно ту же природу в корутинах. Исключением является CancelationException, которое может быть частью нормального поведения.

Может есть какой то пример кода, сейчас звучит как будто можно улучшить то как эта корутина написана, SupervisorScope имеет смысл, но в относительно специфичных кейсах и в большинстве suspend функий смысла в нем нет

я думаю тут больше проблема в том как конкретно корутины используются чем общий вопрос

@gildor Спасибо за совет! В итоге, сделал именно sealed классы для каждого варианта. Но, всё же, интересно, почему выбрано именно такое поведение корутин по-умолчанию

val scope = CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO>)

scope.async {
	
	// Я хочу обработать exception здесь 
	// и не пробрасывать его на уровень выше,
	// но он пробрасывается
	val result = try { 
		otherCallAsync(this).await()
	} catch (e: Exception) {
		fallback
	}

	result
}

fun otherCallAsync(scope: CoroutineScope) = scope.async {
	throw RuntimeException("no internet")
}

Попозже скину почему такое поведение выбрано, что бы не отменять скоуп и обработать ошибку руками просто создайте CoroutineScope передав SupervisorJob

@gildor Добрый день! Можете, пожалуйста, скинуть материалы по поводу этого поведения?

Ох. забыл

@gildor Спасибо за материалы! Раньше не видел issue на github. Стало понятнее, почему было принято такое решение. Оно действительно оптимально для бэка, где у нас много клиентов на одной ноде. Нам async нужен именно для parallel исполнения, а не concurrent. За счёт того, что клиентов много и они исполняются concurrently и так, мы эффективно утилизируем ресурсы. Если бы мы использовали async внутри handler’ов - нам бы это ничего не дало так как просто бы выросла очередь. Но на мобилках другой кейс. Мы хотим доставить данные пользователю как можно скорее и если что-то отвалится - всё равно что-то показать. Чаще всего, одновременно исполняется только один Interactor, но он ходит в несколько источников. И все они нестабильны. И интернет плохой. Поэтому хочется использовать что-то для решения этой проблемы, но async не подходит, а альтернатив в корутинах я не знаю. Именно поэтому возник такой вопрос.

@adev_one Не уверен что это как то отличается при использовании на бэкенде или на клиенте, и там и там есть разные юз кейсы, подходящие под разные способы использования лайфсайкла корутин Не понимаю почему вы пишите, что async не подходит, просто используйте SupervisorJob:

val scope = CoroutineScope(SupervisorJob () + <http://Dispatchers.IO|Dispatchers.IO>)

Мои комменты выше были по отношению к стилю того как вы ваш код групируете, что если есть возможность, лучше использовать только suspend функции и паралелить их врапая в async, но только на месте вызова, где можно будет легко обработать ошибку, это просто то как рекомендуется в официальном гайде это делать, опять же там где возможно и это зависит от юз кейса и если у вас есть пример кода, то как вы используете корутины, то можно было бы более предметно поговорить