не советую.
но например внутри интерфейса я не хочу придумывать какой-то специальный sealed или, тем более, использовать Result.
Сделал это через механизм OptIn, и планирую продолжать плодить такие аннотации, когда хочу разрешить выкидывать ошибки внутри методов зависимостей.
Т.к. я делаю библиотеку, оно вряд-ли протечёт к конечному пользователю, но как внутренний инструмент, мне кажется, довольно хорошая идея. Есть ли у кого-то мысли по этому поводу?
Меня бы бесило делать Optin, и при этом реально не защитит. Хватит просто аннотации + дока
ещё раз, это скорее внутренний механизм внутри библиотеки, чтобы точно знать какие методы чистые, а какие опасные. оно у меня на уровне error, потому что я как раз хочу во всех местах использования явно показывать, что я помню про ошибку и хочу её игнорить/обработать.
Котлинисты изобрели checked exceptions 😂
А чего такое отвращение к Result?
тоже стало интересно почему принципиальность против result :/
наверное потому что result нужно не забыть обработать
А чем kdocs не устроила?
Нет, пихать его везде неудобно банально + не эффективно
в этом контексте конечно понятно, я уже было подумал что что-то с подходом не так
тем, что когда я вызываю функцию, я его не прочитаю
я перед этим ныл в лс, что жалко в котлине нет проверяемых ошибок, и как раз этого и хотел добиться, так что да....
А по-сути нужен лишь механизм предупреждения. К слову о kdocs - а нельзя настроить на варнинги необработанных исключений, если исключения из @throws документации никак не обрабатываются?
честно говоря не знаю, но оптин может быть таким же варнингом
к тому же там далее инспекция сложная, если я захочу не обрабатывать в этой функции, а указать throws в kdoc
Обсуждают сегодня