Pull to refresh

Comments 15

Зачем писать еще одну библиотеку, если в котлине уже есть стандартный Result у которого замечательный API? То что его нельзя возвращать даже плюс, так как все что вам нужно в таком случае делать — возвращать из функций чистые данные, а обрабатывать ошибки во ViewModel. Получается простой синхронный код без ненужных оберток.
Не считаю код из вашего примера более простым.

Допустим, вы делаете запрос к серверу, который вернет либо данные, либо ошибку, что данные не найдены. Оба состояния — это бизнес логика, поэтому приходят с HTTP Result 200.
В моем случае, они обернуться в Reaction.Success и Reaction.Error. В вашем — придется делать дополнительный класс для передачи данных, либо кидать Exception на ошибку от сервера…
В стандарте очень не хватает обработки пустого результата. Это и не null, и вроде как и не ошибка.
Вот из-за такого приходится велосипедить свою реализацию промисов.

Как пример можно посмотреть на реализацию класса Result из корутин пакета.

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

На самом деле можно, но Throwable является их суперклассом, поэтому для использования ничего не поменяется.

Я имел ввиду, почему не делать, чтоб функция возвращала данные в случае успеха и кидала исключение при ошибке?

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

По сути, единственное, что меняется, в случае использования reaction, result, вместо try-catch — это что ошибка будет трансформироваться в другой класс, что по сути, затрудняет понимание происходящего, а количество кода не уменьшает. Как использовалась куча условий для обработки ошибки, так и будет. Только в случае с try-catch, мы имеем более логичный результат — это будут либо чистые данные, либо ошибку, которую мы и так ожидаем.


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

Почитайте статью Елизарова — Kotlin and Exceptions.
Суть в том, что исключения не совсем тру. В вашем случае ошибка — это не исключение, а результат, пусть и отрицательный.

Сейчас почти каждый «современный» Android(Kotlin) проект содержит это решение и у каждого название разное (Reaction, Result, ResultModel, ResultType etc.) но цель одна :)
Мне одному кажется идея с zip костылем? У вас есть Repository, который
возвращает Reaction [Success, Error]. Вы тупо мапите его в свой класс
вида State [Progress, Success, Error] что бы воткнуть такой же when где-то
в подписке на LiveData. В чем прикол?
Sign up to leave a comment.

Articles

Change theme settings