Обработка исключений в Java в функциональном стиле. Часть 2.

В предыдущей статье была рассмотрена функциональная обработка исключений с помощью интерфейса Try<T>. Статья вызвала определенный интерес читателей и была отмечена в «Сезоне Java».

В данной статье автор продолжит тему и рассмотрит простую и «грамотную» (literate) обработку исключений при помощи функций высшего порядка без использования каких либо внешних зависимостей и сторонних библиотек.

Решение

Для начала перепишем пример из предыдущей статьи преобразования URL из строкового представления к объектам URL c использованием Optional.

    public List<URL> urlList(String[] urls) {         return Stream.of(urls)      //Stream<String>         .map(s -> {             try {                 return Optional.of(new URL(s));             } catch (MalformedURLException me) {                 return Optional.empty();             }             })                      //Stream<Optional<>URL>         .flatMap(Optional::stream)  //Stream<URL>, filters empty optionals         .toList();     }

Общая схема понятна, однако не хотелось бы писать подобный boilerplate код каждый раз когда мы встречается с функцией выбрасывающей проверяемые исключения.

И тут нам помогут следующие функции:

    @FunctionalInterface     interface CheckedFunction<T, R> {         R apply(T t) throws Exception;     }      /**      * Higher-order function to convert partial function T=>R to total function T=>Optional<R>      * @param <T> function input parameter type      * @param <R> function result type      * @param func partial function T=>R that may throw checked exception      * @return total function T => Optional<R>      */     static <T, R> Function<T, Optional<R>> toOptional(CheckedFunction<T, R> func) {         return param -> {             try {                 return Optional.ofNullable(func.apply(param));             } catch (RuntimeException err) {                 throw err;  //All runtime exceptions are treated as errors/bugs             } catch (Exception e) {                 return Optional.empty();             }         };     }

Дадим некоторые пояснения. CheckedFunction<T, R> это функция которая может выбросить исключение при преобразовании T => R. Подобные функции в терминах функционального программирования называются частичными (partial) функциями, потому что значение функции не определено при некоторых входных значениях параметра.

Функция toOptional(...) преобразует частичную (partial) функцию T => R в полную (total) функцию T => Optional. Подобного рода функции, которые принимают параметром и/или возвращают другую функцию, в терминах функционального программирования называются функциями высшего порядка (higher-order function).

С использованием новой функции код примет следующий опрятный вид:

    public List<URL> urlList(String[] urls) {         return Stream.of(urls)      //Stream<String>         .map(toOptional(URL::new))  //Stream<Optional<URL>>         .flatMap(Optional::stream)  //Stream<URL>, filters empty optionals         .toList();                  //List<URL>     }

И теперь её можно применять везде где возможны проверяемые (checked) исключения.

    List<Number> intList(String [] numbers) {         NumberFormat format = NumberFormat.getInstance();         return Stream.of(numbers)       //Stream<String>          .map(toOptional(format::parse)) //Checked ParseException may happen here         .flatMap(Optional::stream)      //Stream<Number>         .toList();                      //List<Number>     }

Улучшаем обработку исключений

При использовании Optional<T> пропадает информация о самом исключении. В крайнем случае исключение можно залогировать в теле функции toOptional, но мы найдем лучшее решение.

Нам нужен любой контейнер, который может содержать значение типа T либо само исключение. В терминах функционального программирования таким контейнером является Either<Exception, T>, но к сожаления класса Either<L,R> (как и класса Try<T>) нет в составе стандартной библиотеки Java.

Вы можете использовать любой подходящий контейнер, которым Вы обладаете. Я же в целях краткости буду использовать следующий

    //Require Java 14+     record Result<T>(T result, Exception exception) {         public boolean failed() {return exception != null;}         public Stream<T> stream() {return failed() ? Stream.empty() : Stream.of(result);}     } 

Теперь наша функция высшего порядка получит имя toResult и будет выглядеть так:

    static <T, R> Function<T, Result<R>> toResult(CheckedFunction<T, R> func) {         return param -> {             try {                 return new Result<>(func.apply(param), null);             } catch (RuntimeException err) {                 throw err;             } catch (Exception e) {                 return new Result<>(null, e);             }         };     }

А вот и применение новой функции toResult()

    List<Number> intListWithResult(String [] numbers) {         NumberFormat format = NumberFormat.getInstance();         return Stream.of(numbers)      //Stream<String>         .map(toResult(format::parse))  //Stream<Result<Number>>, ParseException may happen         .peek(this::handleErr)         //Stream<Result<Number>>         .flatMap(Result::stream)       //Stream<Number>         .toList();                     //List<Number>     }      void handleErr(Result r) {         if (r.failed()) {             System.out.println(r.exception());         }     }

Теперь возможное проверяемое исключение сохраняется в контейнере Result и его можно обработать в потоке.

Выводы

Для простой и «грамотной» (literate) обработки проверяемых (checked) исключений в функциональном стиле без использования внешних зависимостей необходимо

1. Выбрать подходящий контейнер для хранения результата. В простейшем случае это может быть Optional<T>. Лучше использовать контейнер который может хранить значение результата или перехваченное исключение.

2. Написать функцию высшего порядка которая преобразует частичную функцию T => R, которая может выбросить исключение, в полную функцию T => YourContainer<R> и применять ее в случае необходимости.

Ссылки

На github-e

JavaDoc

Source Code

Junit tests

Автор — Сергей А. Копылов
e-mail skopylov@gmail.com