Pull to refresh

Comments 11

Ещё одно неочевидное использование метода stream() это более простое преобразование объектного Optional в примитивный, например:


OptionalLong toLong(Optional<Long> o) {
    return  o.stream().mapToLong(Long::longValue).findAny();
}
Спасибо. Ценное дополнение к тесту статьи.
С нетерпением жду Вашей реализации монады Error.
Вынужден Вас огорчить. Класс будет называться Result. (Шутка)
Давайте же взглянем и на эту утку.
По поводу последнего вашего замечания — не кажется ли вам, что это перебор?
Сам класс опционал подразумевает, что он может содержать в себе пустые элементы. Тут возможны два варианта — либо опционалы вам не нужны и объекты должны жестко существовать, либо метод, возвращающий null, не должен быть вызван.
В любом случае, отлов ошибок получения данных ужа на этапе использования — плохая затея, хотя бы потому, что защита от дурака не сработала ранее.
Выходит, что опционал вам именно в этом случае должен быть не нужен, и даже противопоказан.
Класс о котором я хочу рассказать в следующей статье возник при попытке найти решение реальной задачи. На абстрактном уровне постановка задачи звучит так: вы обращаетесь к некому сервису, который в случае успеха должен вернуть обьект. А причин для неудачи может быть несколько. И логика обработки ошибочной ситуации зависит от того, какова была причина неудачи.
Если сервис возвращает Optional, о причине мы ничего не узнаем. Значит надо использовать что-то похожее на Optional, но содержащее информацию об ошибке в случае неуспеха.
Optional в этом случае действительно недостаточен. О том и будет статья.
Жду. Вообще спасибо, не хватает хабру вот таких жизненных циклов, выстраданных определенной тематикой.
Спасибо на добром слове. Потороплюсь.
Осень похоже. Я выбрал строгое закрепление ролей за первым и вторым типом. Первый отвечает за успех, второй за информацию о проблемах. Поэтому класс называется Result<SUCCESS, FAILURE> Но теоретически пользователь может их использовать с точностью до наоборот.
Sign up to leave a comment.

Articles