(
Ну, то есть будет что-то вроде Either<MyError, T>?
Size: a a a
2021 May 15
VP
Как вариант, sealed с этими ошибками и Succes<T>
KD
В твоём кейсе — да.
@noraltavir бы вот без итера сделал.
@noraltavir бы вот без итера сделал.
I
Так отличие гуглового кода от другого кода в том, что он не зависит от языка программирования. Будет один и тот же говнокод, что на джаве, что на плюсах, что на питоне, что на котлине. Никакого понятия об идиоматичности.
KD
Да, думаю примерно такой вариант и противопоставляют.
VP
Ну такого я ещё не видел
AN
Я бы не стал заворачивать ошибку точно. Если это именно что исключительная ситуация, ошибка должна быть прокинута. Если это не исключительная ситуация, то надо прокидывать данные, а не ошибку.
VP
Это что-то среднее между errno и CancellationToken из C#
VP
Что для одного уровня исключительная ситуация, то для другого норма
KD
Так
Either<Error, Success> и есть прокидывание данных, если Error у нас не Throwable.KD
Ведь о том и речь, что
Error тут у нас свой силд класс с ошибками.AN
Ну значит ошибка должна быть перехвачена на том уровне, где ситуация перестала быть исключительной. Тут единственный вопрос про то, что "можно забыть", но решается на уровне аннотаций.
KD
object UserInputIsBullshit : ErrorVP
Каких аннотаций?
AN
@Throws. Он по-моему до сих пор не полностью функциональный, но можно закостылить при помощи @RequiresOptInVP
Он не умеет ничего, кроме добавления метаданных в байткод
VP
Не говоря уже о том, что это не идиоматично
AN
Ну я же говорю, что не работает. Не понятно, кстати почему. Тот же RequiresOptIn делает то же самое и отлично работает.
AN
Почему это?
AN
Это мета-информация, которая говорит, что ошибка должна быть обработана или прокинута выше. На семантику не влияет