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

которой думаю весь отпуск (уже 2 недели). Как, всё-таки правильно обрабатывать ошибки. Сразу предупреждаю, что я попробовал действительно много всего, но пока что мне ничего не подходит.

И так, начнём с того, как это принято в котлине: стараемся не кидать ошибки, конвертируем ошибки в значения (toIntOrNull(), etc.), но если это ошибка логики, то кидаем как можно быстрее (Fail Fast!).

И вот в этом всём упускается один очень важный момент. Как жить с ошибками, которые кидаются в зависимости от состояния среды? (например, IO) Очень хороший поинт есть в статье @relizarov:

> The special thing about input/output errors is that they are handled in a centralized way by reporting an input/output problem to end-users and/or retrying an operation.

И это работало! Всё время, пока я писал бекенд/ботов/whatever – приложения с одной точкой входа – это работало. Я просто поставил хендлер на ошибки, там где надо, в одном места, и никаких проблем. Но ведь есть и другие приложения – например андроид. Здесь точек входа куча: активити/фрагменты/сервисы. И везде этот самый хендлер надо не забыть поставить.

А если это самое IO крашится только при очень странных обстоятельствах, и сервис используется очень редко, а ещё там корутины неправильно кто-то заиспользовал и стектрейс корявый, то ошибку вообще никак не отловить. На один такой баг я потратил неделю! Хотя это произошло только один раз – теперь по вечерам я мозгую над тем, как этот процесс можно исправить. Я хочу сделать ошибки явными, но при этом не жервтовать простотой кода.

Решение для меня казалось очевидным – завезти монаду Either и сконвертировать все ошибки в значения. Но это не сработало. Оказалось, что у меня больше одной такой ошибки. Я стал получать возвращаемые типы вида Either<ConnectionFailure, Either<AuthFailure, Either<GetUserFailure, User>>>. И это при условии, что это всё комбинируется с sealed interface (в ConnectionFailure 2 значения – HostNotFound, BadRequest, и т.п.). Для меня это кажется неприемлемым, и я пошёл искать другие варианты.

Кроме того, я попробовал полностью на sealed interface – получилось слишком много бойлерплейта. Я даже пробовал контексты под это дело подвести, но не завелось.

Помню в оффтопе @ilmirus писал лонгрид на тему checked или runtime, возможно тебе есть что добавить

Юзай контексты, Люк. class ErrorCoeffect<T: Throwable> inline fun <reified T: Throwable> catching(crossinline c: context(ErrorCoeffect<T>) () -> Unit): Result<Unit> { try { c(ErrorCoeffect()) } catch(t: Throwable) { if (T::class.java.isInstance(t)) { return Result.failure(t) } else { throw t } } }

Маркерные контексты? Обожаю.

А, все, почитал что там @y9san9 выше написал, чекеды поверх context, это весело конечно @y9san9 посмотри еще конец доклада про Arrow который был с @fundamentalparticle https://www.youtube.com/watch?v=g79A6HmbW5M

T::class.java еще может взорваться с какими-нибудь @JvmInline value class

А че, такие экспешены можно нынче в котлине делать?

спасибо! а можно таймкод?

Ну так это же и “хорошо”

Список может быть настолько большой что его некомфортно поддерживать, поэтому в реальных приложениях был один BusinessException от которого все наследовалось и враппилось. Не хватает ad-hoc sealed типов, аля: sealed typealias BusinessException = BusinessDaoException | BusinessServiceException | BusinessApuException и тогда в coeffect положить <T : BusinessException>

это можно порешать через KT-13108

который непонятно когда :(