Мотивация

Поводом к написанию этой статьи стал "Pragmatic FP" манифест
в котором автор утверждает что прагматичное функциональное программирование (далее FP) требует использования всего двух монад - Option<T> и Result<T>.

Данная статья в некотором смысле развивает идеи "Pragmatic FP" и утверждает что
прагматичное FP можно делать с помощью всего одной монады - XResult<T>

Проблема

В функциональном программировании традиционно существует три монады для
обработки/представления отказов (errors).

• Option<T>/Maybe<T> - для представления отсутствующего результата (null значение)

• Result<T>/Try<T> - для обработки случаев когда получение результата может завершиться исключением (exception)

• Either<L,R> - для всех остальных случае. Левое значение L традиционно ассоциируется с отказом, правое R - c успешным результатом.

В Java Result и Either монады отсутствуют в составе стандартной библиотеки, Optional появился в Java8, однако его дизайн не идеален и часто критикуется,
для примера тут, в Oracle Java Magazine

Следующей общей проблемой в Java для всех монад является то, что разные монады плохо сочетаются (compose), а точнее совсем не сочетаются при помощи стандартной для этого операции flatMap(). Для примера, попробуйте скомбинировать Optional и Result. Без использования isPresent() и isSuccess() у вас это не получится, что делает использование FP в данном случае сомнительным.

Далее, в реальной жизни возможностей Optional и Result часто бывает недостоточно. Рассмотрим пример простой классической функции.

public User getUserById(long id);

С точки зрения FP, данная функция всегда возвращает пользователя, а на практике данная функция может

• вернуть пользователя User

• вернуть null

• выбросить Runtime исключение

• результат может зависеть от фазы Луны ;)

Представим себя на месте автора этой функции. Как сделать эту функцию безопасной? Так?

public Optional<User> getUserById(long id);

Не пойдет, может быть выброшено исключение. Так?

public Result<Optional<User>> getUserById(long id);

Нет, это уже слишком. Но и это еще не всё. Представим себе что мы получаем пользователя по REST API и на HTTP запрос получили ответ с кодом из серии 400-500. То есть причиной сбоя (error cause) является не null значение и не исключение, а ошибка HTTP протокола. Как сделать функцию безопасной, что вернуть в случае отказа? Ответ - монаду XResult<T>

Что в имени тебе моём ...

X в имени XResult<T> означает

• eXtended - расширенный. XResult одновременно обладает свойствами Option<T>, Result<T> и Either<L,R>

• eXtensible - расширяемый. Вы можете легко добавлять новые причины отказов (ErrCause) для вашей предметной области. (problem domain).

Ниже на диаграмме показан дизайн монады XResult. Он прост и традиционно имеет базовый класс XResult и двух потомков - Ok, который содержит результат типа T и Err, который содержит причину отказа ErrCause. ErrCause - маркерный интерфейс, который не накладывает никаких обязательств для имплементирующих этот интерфейс. XResult предоставляет три имплементации ErrCause

• ExceptionCause - исключение

• FilterCause - фильтрация с указанием возможной причины

• SimpleCause - причина сбоя которая описывается простой строкой.

Как мы видим, отсутствует NullCause, в котором нет особенной нужды. Вместо NullCause используется ExceptionCause с исключением NullPointerException, которое создается в момент обнаружения null значения (разумеется вместе с stack-trace, который позволяет обнаруживать место возникновения проблемы)

XResult на практике

Попробуем решить указанную выше задачу получения пользователя при помощи XResult

XResult<User> user = XResult.fromCallable(() -> getUserById(100));

Статическая функция XResult.fromCallable() обработает возможные исключения и нулевые результаты и вернет пользователя (или ошибку) упакованную в XResult. Далее с ним можно делать всё что угодно, как и с любой другой монадой - map(), flatMap(), filter() и др.

Теперь представим себя на месте писателя этой функции. Чтобы сделать функцию безопасной для применения, мы определим её следующим образом:

public XResult<User> getUserById(long id) {
}

Из тела этой функции мы вернем

• XResult.ofNullable(user) - когда пользователь user получен по сети, null значение обработается автоматически

• XResult.err(exception) - когда мы перехватим любое исключение exception

• XResult.err("HTTP error 401") - в случае ошибок HTTP протокола

Давайте расширим обработку HTTP ошибок для того чтобы вызывающая сторона могла получить больше информации об ошибке. Для этого определим класс HttpError

public class HttpError implements ErrCause {
    int resultCode;
    String errorDescription;
    String method;
    String url;
    ...
}

Тогда при выявлении HTTP ошибки мы сделаем следующее

    if (httpResponse.getCode() >= 400) {
        HttpError httpErr = new HttpError(httpResponse);
        return XRresult.err(httpErr);
    }

На вызывающнй стороне HttpError можно получить следующим образом:

    XResult<User> user = getUserById(100);
    user.on( ok -> {
        // обработка успеха
        },
        err -> {
          if (err instanceof HttpError)) {
                HttpError httpErr = (HttpError) err;
                int code = httpErr.getResutCode();
          }
        })

В итоге

Монада XResult<T>

• обладает свойствами Optional<T>, Result<T> и Either<L,R>

• легко расширяется для создания причин отказов ErrCause в вашей предметной области

• позволяет применять FP в легаси проектах и создавать безопасные API в новых проектах

• имеет компактный дизайн и API javadoc

• имплементирован в одном исходном файле (~260 строк кода с подробным javadoc)

• 100% покрыт юнит тестами

• не имеет run-time зависимостей

• размещен на Github

Для компиляции используется Java версии 8 (JavaLanguageVersion.of(8)),
это сделано преднамеренно, потому что может возникнуть необходимость
применить XResult для древнего легаси.

При использовании Java 17+ код XResult может быть легко переписан с использованием
запечатанных (sealed) интерфейсов, записей (records), сопоставления с образцом
(pattern matching), что сделает код еще более коротким и удобным в использовании.
Но это на будущее.

Сергей Копылов