VP
Чем вылетевший из функции RuntimeException отличается от лежащего в возвращённом оттуда Result мне не ясно
Size: a a a
2020 April 21
AM
Тогда надо за любой RuntimeException наказывать, ибо оно может вылететь откуда угодно, в т.ч. из кода, который оперирует Result, если там окажется баг
Ну я же образно :) Я к тому, что пролетевший мимо эксепшн -- это совсем уж исключительная ситуация, удел которой -- отправиться в дефолтный обработчик.
VP
ну смысл result в том, что он несёт в себе checked exception как раз
Там, кажется, Throwable
AM
Если код возвращает резалты, очевидно, что он декларирует конкретный способ сообщения об ошибках, не предполагающий их бросание.
VP
А значит это отличная возможность по-тихому проглотить критичную ошибку (OOM, LinkageError и вот это всё)
QH
Там, кажется, Throwable
Ну так типа
Но по факту RuntimeException имеет смысл кинуть, а checked — вернуть.
CheckedException не существует.Но по факту RuntimeException имеет смысл кинуть, а checked — вернуть.
VP
Ну так типа
Но по факту RuntimeException имеет смысл кинуть, а checked — вернуть.
CheckedException не существует.Но по факту RuntimeException имеет смысл кинуть, а checked — вернуть.
По факту внутри Result может лежать всё, что угодно.
Когда мы делаем
Когда мы делаем
runCatching { foo() } нет вообще никаких гарантий, что там внутри будет checked exception.VP
Для ожидаемых ситуаций, которые надо обработать, надо не исключения использовать просто 🙂
QH
По факту внутри Result может лежать всё, что угодно.
Когда мы делаем
Когда мы делаем
runCatching { foo() } нет вообще никаких гарантий, что там внутри будет checked exception.Дак я не говорю, что есть гарантии. Я говорю, что Result имеет смысл возвращать, чтобы явно задекларировать ошибку.
Но Either, конечно, круче.
Но Either, конечно, круче.
VP
Дак я не говорю, что есть гарантии. Я говорю, что Result имеет смысл возвращать, чтобы явно задекларировать ошибку.
Но Either, конечно, круче.
Но Either, конечно, круче.
Был бы смысл, если бы эту ошибку в Result было бы обрабатывать удобнее/надёжнее, чем если её просто выкинуть
BP
я ведь правильно помню, что kotlin.Result с 1.4 можно будет возвращать из функций? т.е. в новом проекте относительно спокойно можно уже завязаться на нём, вместо сторонних решений или своих костылей. а как-то отрубить его подчеркивание и ошибку в IDE можно? аргумент компилятору добавил, код компилится успешно, а вот ошибка в эдиторе не пропала..
Ещё нужно аннотацию OpIn, могу завтра посмотреть
BP
Был бы смысл, если бы эту ошибку в Result было бы обрабатывать удобнее/надёжнее, чем если её просто выкинуть
Ее и можно обработать, или что подразумевается под "обработать" ?
BP
Но ведь возвращать Result с исключением внутри - это практически то же самое. Только исключение ещё бонусом может пролететь мимо Result.
Обрабатывать ошибки с помощью Result, я думаю, может быть удобно, но зачем его возвращать - не очень понимаю.
Обрабатывать ошибки с помощью Result, я думаю, может быть удобно, но зачем его возвращать - не очень понимаю.
Ну например результат вставки/удаления из бд, можно вручную обработать, но придется предугадывать все варианты
D
Ее и можно обработать, или что подразумевается под "обработать" ?
чот не, ни аргумент
-Xopt-in=kotlin.RequiresOptIn, ни languageSettings.useExperimentalAnnotation("kotlin.RequiresOptIn") в сорс сете не помогли. та и ладно, не надо уже, я решил отказаться от его использования)AN
А оно такое только в этой функции выдает. Этот SecretValue ваш или библиотечный?
BV
А оно такое только в этой функции выдает. Этот SecretValue ваш или библиотечный?
Всё моё
BP
чот не, ни аргумент
-Xopt-in=kotlin.RequiresOptIn, ни languageSettings.useExperimentalAnnotation("kotlin.RequiresOptIn") в сорс сете не помогли. та и ладно, не надо уже, я решил отказаться от его использования)Нужно на метод вешать, альт ентер должен подсказать
BV
А оно такое только в этой функции выдает. Этот SecretValue ваш или библиотечный?
Да, другого места я пока не видел
AN
Всё моё
Спасибо, буду поизучать