Створіть спеціальний тип повернення, який поширюватиме перевірений виняток. Це альтернатива створенню нового інтерфейсу, який відображає існуючий функціональний інтерфейс з незначною модифікацією «викидання викидів» методу функціонального інтерфейсу.
Визначення
ПеревіренийValueSupplier
public static interface CheckedValueSupplier<V> {
public V get () throws Exception;
}
Перевірено
public class CheckedValue<V> {
private final V v;
private final Optional<Exception> opt;
public Value (V v) {
this.v = v;
}
public Value (Exception e) {
this.opt = Optional.of(e);
}
public V get () throws Exception {
if (opt.isPresent()) {
throw opt.get();
}
return v;
}
public Optional<Exception> getException () {
return opt;
}
public static <T> CheckedValue<T> returns (T t) {
return new CheckedValue<T>(t);
}
public static <T> CheckedValue<T> rethrows (Exception e) {
return new CheckedValue<T>(e);
}
public static <V> CheckedValue<V> from (CheckedValueSupplier<V> sup) {
try {
return CheckedValue.returns(sup.get());
} catch (Exception e) {
return Result.rethrows(e);
}
}
public static <V> CheckedValue<V> escalates (CheckedValueSupplier<V> sup) {
try {
return CheckedValue.returns(sup.get());
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}
Використання
// Don't use this pattern with FileReader, it's meant to be an
// example. FileReader is a Closeable resource and as such should
// be managed in a try-with-resources block or in another safe
// manner that will make sure it is closed properly.
// This will not compile as the FileReader constructor throws
// an IOException.
Function<String, FileReader> sToFr =
(fn) -> new FileReader(Paths.get(fn).toFile());
// Alternative, this will compile.
Function<String, CheckedValue<FileReader>> sToFr = (fn) -> {
return CheckedValue.from (
() -> new FileReader(Paths.get("/home/" + f).toFile()));
};
// Single record usage
// The call to get() will propagate the checked exception if it exists.
FileReader readMe = pToFr.apply("/home/README").get();
// List of records usage
List<String> paths = ...; //a list of paths to files
Collection<CheckedValue<FileReader>> frs =
paths.stream().map(pToFr).collect(Collectors.toList());
// Find out if creation of a file reader failed.
boolean anyErrors = frs.stream()
.filter(f -> f.getException().isPresent())
.findAny().isPresent();
Що відбувається?
Створюється єдиний функціональний інтерфейс, який видає перевірений виняток (CheckedValueSupplier ). Це буде єдиний функціональний інтерфейс, який дозволяє перевіряти винятки. Усі інші функціональні інтерфейси будуть використовувати CheckedValueSupplierдля обгортання будь-якого коду, який видає перевірений виняток.
The CheckedValueКлас буде містити результат виконання будь - якої логіки, що генерує перевіряється виключення. Це запобігає розповсюдженню перевіреного винятку до моменту, коли код намагається отримати доступ до значення, яке містить екземпляр CheckedValue.
Проблеми з таким підходом.
- Зараз ми кидаємо "Виняток", фактично приховуючи певний тип, спочатку кинутий.
- Ми не усвідомлюємо, що виняток стався до
CheckedValue#get()виклику.
Споживач та ін
Деякі функціональні інтерфейси (Consumer наприклад) повинні оброблятися по-різному, оскільки вони не забезпечують зворотного значення.
Функція замість споживача
Один із підходів - використовувати функцію замість споживача, яка застосовується під час обробки потоків.
List<String> lst = Lists.newArrayList();
// won't compile
lst.stream().forEach(e -> throwyMethod(e));
// compiles
lst.stream()
.map(e -> CheckedValueSupplier.from(
() -> {throwyMethod(e); return e;}))
.filter(v -> v.getException().isPresent()); //this example may not actually run due to lazy stream behavior
Ескалат
Крім того, ви завжди можете перейти до "a" RuntimeException. Є й інші відповіді, які охоплюють ескалацію перевіреного винятку зсередини Consumer.
Не споживайте.
Просто уникайте функціональних інтерфейсів разом і використовуйте гарну модель для циклу.
