Разрешено ли выбрасывать метод, который возвращает Try? - PullRequest
Новая
       53

Разрешено ли выбрасывать метод, который возвращает Try?

2 голосов
/ 07 апреля 2020

Мы используем Vavr в нашем проекте, чтобы упростить обработку исключений. Я всегда проверяю, чтобы метод, который возвращает Try, никогда не мог ничего выдать, например: 

public Try<Result> someSafeMethod() {
  return Try.of(() -> someService.generateId())
           .map(someOtherService::getValueForId)
           .map(mappingService::mapToResult);
}

, но некоторые из моих коллег реализовали бы его так: 

public Try<Result> someSafeMethod() {
  String generatedId = someService.generateId(); // <- Might throw an Exception that is not caught by the Try clause
  return Try.of(() -> someOtherService.getValueForId(generatedId))
           .map(mappingService::mapToResult);
}

Утверждение, что если что-то не так с генерацией идентификатора, то вместо исключения выдается Try, являющийся ошибкой.

Документация не запрещает метод, возвращающий Try, не должен выбрасывать, но он утверждает, что:

Try - это тип контейнера monadi c, который представляет вычисление, которое может привести к исключению или вернуть успешно вычисленное значение .

Я слишком строг? Представьте, что вы используете API, где все методы возвращают Try, не будет ли плохо, если они все еще выдают?

1 Ответ

2 голосов
/ 07 апреля 2020

Вы не слишком строги.

Весь смысл использования Try в качестве возвращаемого значения - это получаемое в результате преимущество программирования с полными функциями и наличия компонованного способа обработки ошибок. Итоговые функции - это функции, которые всегда возвращают значение объявленного возвращаемого типа для всех возможных значений аргумента. Если они генерируют исключения, их функции больше не являются целыми функциями, и - без явной обработки ошибок - не тотальность будет распространяться транзитивно через их код, «заражая» все другие функции, которые вызывают их неуниверсальностью. В результате они получат код, о котором будет гораздо сложнее рассуждать, и потребуется больше усилий, чтобы убедиться в его правильности.

Бросок исключений при использовании Try также не соответствует цели использование Try в первую очередь, и это излишне усложнит код, потребляющий их API, без какой-либо очевидной выгоды, поскольку потребители API должны будут обрабатывать ошибки, используя Try и перехват исключений.

...