вы действительно можете продлить Consumer (и Function etc.) с новым интерфейсом, который обрабатывает исключения ... с помощью Java 8-х методы по умолчанию!

рассмотрим этот интерфейс (extends Consumer):

@FunctionalInterface
public interface ThrowingConsumer<T> extends Consumer<T> {

    @Override
    default void accept(final T elem) {
        try {
            acceptThrows(elem);
        } catch (final Exception e) {
            // Implement your own exception handling logic here..
            // For example:
            System.out.println("handling an exception...");
            // Or ...
            throw new RuntimeException(e);
        }
    }

    void acceptThrows(T elem) throws Exception;

}

тогда, например, если у вас есть список:

final List<String> list = Arrays.asList("A", "B", "C");

если вы хотите потреблять его (например. с forEach) С некоторым кодом, который выдает исключения, вы традиционно создали бы блок try / catch:

final Consumer<String> consumer = aps -> {
    try {
        // maybe some other code here...
        throw new Exception("asdas");
    } catch (final Exception ex) {
        System.out.println("handling an exception...");
    }
};
list.forEach(consumer);

но с помощью этого нового интерфейса вы можете создать его экземпляр с лямбда-выражением, и компилятор не будет жаловаться:

final ThrowingConsumer<String> throwingConsumer = aps -> {
    // maybe some other code here...
    throw new Exception("asdas");
};
list.forEach(throwingConsumer);

или даже просто бросить его на более емкий!:

list.forEach((ThrowingConsumer<String>) aps -> {
    // maybe some other code here...
    throw new Exception("asda");
});

обновление: похоже, есть очень хорошая часть библиотеки утилит дуриан под названием ошибки который можно использовать для решения этой проблемы с гораздо большей гибкостью. Например, в моей реализации выше я явно определил ошибку Политика обработки (System.out... или throw RuntimeException), в то время как ошибки Durian позволяют применять политику "на лету" с помощью большого набора методов утилиты. Спасибо разделяя его, @NedTwigg!.

пример использования:

list.forEach(Errors.rethrow().wrap(c -> somethingThatThrows(c)));

Я думаю дуриана Errors класс сочетает в себе многие плюсы различных предложений.

• оберните функцию метания в стандартный функциональный интерфейс Java 8.
• указать различные политики для обработки ошибок
• при обертывании метода, который возвращает значение, есть важное различие между указанием значения по умолчанию или переосмыслением Исключение RuntimeException.
• бросив версии функциональных интерфейсов Java 8
  • аналогично ответ fge
• стандартные интерфейсы для бросания определенных исключений
  • какие адреса беспокойство Золтана

чтобы включить Durian в свой проект, вы можете либо:

• возьмите его из jcenter или maven central at com.diffplug.durian:durian:3.3.0
• или просто скопируйте вставить только два небольших класса в код:Throwing.java и Errors.java

Это не относится к Java 8. Вы пытаетесь скомпилировать что-то эквивалентное:

interface I {
    void m();
}
class C implements I {
    public void m() throws Exception {} //can't compile
}

отказ от ответственности: я еще не использовал Java 8, только читал об этом.

Function<String, Integer> не дает IOException, поэтому вы не можете поместить в него код, который throws IOException. Если вы вызываете метод, который ожидает Function<String, Integer>, тогда лямбда, которую вы передаете этому методу, не может бросить IOException, период. Вы можете либо написать лямбду, как это (я думаю, что это синтаксис лямбда, не уверен):

(String s) -> {
    try {
        return myMethod(s);
    } catch (IOException ex) {
        throw new RuntimeException(ex);
        // (Or do something else with it...)
    }
}

или, если способ вы передаете лямбда-это ты написал себя, вы можете определить новый функциональный интерфейс и использовать его в качестве типа параметра вместо Function<String, Integer>:

public interface FunctionThatThrowsIOException<I, O> {
    O apply(I input) throws IOException;
}

Если вы не возражаете использовать сторонний lib (Vavr) вы могли бы написать

CheckedFunction1<String, Integer> f = this::myMethod;

Он также имеет так называемую монаду Try, которая обрабатывает ошибки:

Try(() -> f.apply("test")) // results in a Success(Integer) or Failure(Throwable)
        .map(i -> ...) // only executed on Success
        ...

подробнее здесь.

отказ от ответственности: я создатель Vavr.

можно использовать обертка unthrow

Function<String, Integer> func1 = s -> Unthrow.wrap(() -> myMethod(s));

или

Function<String, Integer> func2 = s1 -> Unthrow.wrap((s2) -> myMethod(s2), s1);

вы можете.

расширение @marcg ' s UtilException и добавление generic <E extends Exception> при необходимости: таким образом, компилятор заставит вас снова добавить предложения throw, и все так, как если бы вы могли бросить проверенные исключения изначально на потоки java 8.

public final class LambdaExceptionUtil {

    @FunctionalInterface
    public interface Function_WithExceptions<T, R, E extends Exception> {
        R apply(T t) throws E;
    }

    /**
     * .map(rethrowFunction(name -> Class.forName(name))) or .map(rethrowFunction(Class::forName))
     */
    public static <T, R, E extends Exception> Function<T, R> rethrowFunction(Function_WithExceptions<T, R, E> function) throws E  {
        return t -> {
            try {
                return function.apply(t);
            } catch (Exception exception) {
                throwActualException(exception);
                return null;
            }
        };
    }

    @SuppressWarnings("unchecked")
    private static <E extends Exception> void throwActualException(Exception exception) throws E {
        throw (E) exception;
    }

}

public class LambdaExceptionUtilTest {

    @Test
    public void testFunction() throws MyTestException {
        List<Integer> sizes = Stream.of("ciao", "hello").<Integer>map(rethrowFunction(s -> transform(s))).collect(toList());
        assertEquals(2, sizes.size());
        assertEquals(4, sizes.get(0).intValue());
        assertEquals(5, sizes.get(1).intValue());
    }

    private Integer transform(String value) throws MyTestException {
        if(value==null) {
            throw new MyTestException();
        }
        return value.length();
    }

    private static class MyTestException extends Exception { }
}

У меня была эта проблема с классом.forName и Class.newInstance внутри лямбды, поэтому я просто сделал:

public Object uncheckedNewInstanceForName (String name) {

    try {
        return Class.forName(name).newInstance();
    }
    catch (ClassNotFoundException | InstantiationException | IllegalAccessException e) {
        throw new RuntimeException(e);
    }
}

внутри лямбды, вместо вызова класса.forName ("myClass").newInstance () я только что вызвал uncheckedNewInstanceForName ("myClass")

однако вы можете создать свой собственный FunctionalInterface, который бросает, как показано ниже..

@FunctionalInterface
public interface UseInstance<T, X extends Throwable> {
  void accept(T instance) throws X;
}

затем реализуйте его с помощью Lambdas или ссылок, как показано ниже.

import java.io.FileWriter;
import java.io.IOException;

//lambda expressions and the execute around method (EAM) pattern to
//manage resources

public class FileWriterEAM  {
  private final FileWriter writer;

  private FileWriterEAM(final String fileName) throws IOException {
    writer = new FileWriter(fileName);
  }
  private void close() throws IOException {
    System.out.println("close called automatically...");
    writer.close();
  }
  public void writeStuff(final String message) throws IOException {
    writer.write(message);
  }
  //...

  public static void use(final String fileName, final UseInstance<FileWriterEAM, IOException> block) throws IOException {

    final FileWriterEAM writerEAM = new FileWriterEAM(fileName);    
    try {
      block.accept(writerEAM);
    } finally {
      writerEAM.close();
    }
  }

  public static void main(final String[] args) throws IOException {

    FileWriterEAM.use("eam.txt", writerEAM -> writerEAM.writeStuff("sweet"));

    FileWriterEAM.use("eam2.txt", writerEAM -> {
        writerEAM.writeStuff("how");
        writerEAM.writeStuff("sweet");      
      });

    FileWriterEAM.use("eam3.txt", FileWriterEAM::writeIt);     

  }


 void writeIt() throws IOException{
     this.writeStuff("How ");
     this.writeStuff("sweet ");
     this.writeStuff("it is");

 }

}

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

некоторый код для уточнения вещей:

public interface ThrowableFunction<A, B> {
    B apply(A a) throws Exception;
}

public abstract class Try<A> {

    public static boolean isSuccess(Try tryy) {
        return tryy instanceof Success;
    }

    public static <A, B> Function<A, Try<B>> tryOf(ThrowableFunction<A, B> function) {
        return a -> {
            try {
                B result = function.apply(a);
                return new Success<B>(result);
            } catch (Exception e) {
                return new Failure<>(e);
            }
        };
    }

    public abstract boolean isSuccess();

    public boolean isError() {
        return !isSuccess();
    }

    public abstract A getResult();

    public abstract Exception getError();
}

public class Success<A> extends Try<A> {

    private final A result;

    public Success(A result) {
        this.result = result;
    }

    @Override
    public boolean isSuccess() {
        return true;
    }

    @Override
    public A getResult() {
        return result;
    }

    @Override
    public Exception getError() {
        return new UnsupportedOperationException();
    }

    @Override
    public boolean equals(Object that) {
        if(!(that instanceof Success)) {
            return false;
        }
        return Objects.equal(result, ((Success) that).getResult());
    }
}

public class Failure<A> extends Try<A> {

    private final Exception exception;

    public Failure(Exception exception) {
        this.exception = exception;
    }

    @Override
    public boolean isSuccess() {
        return false;
    }

    @Override
    public A getResult() {
        throw new UnsupportedOperationException();
    }

    @Override
    public Exception getError() {
        return exception;
    }
}

простой пример использования :

List<Try<Integer>> result = Lists.newArrayList(1, 2, 3).stream().
    map(Try.<Integer, Integer>tryOf(i -> someMethodThrowingAnException(i))).
    collect(Collectors.toList());

эта проблема беспокоила меня также; Вот почему я создал этот проект.

С ним вы можете сделать:

final ThrowingFunction<String, Integer> f = yourMethodReferenceHere;

существует тотла из 39 интерфейсов, определенных JDK, которые имеют такой Throwing эквивалент; это все @FunctionalInterfaceS используется в потоках (база Stream, но и IntStream, LongStream и DoubleStream).

и по мере того как каждый из них расширяет их non бросая двойника, вы можете сразу использовать их в lambdas как хорошо:

myStringStream.map(f) // <-- works

поведение по умолчанию является то, что когда ваш бросок лямбда бросает проверенное исключение,ThrownByLambdaException выбрасывается с проверенным исключением в качестве причины. Поэтому вы можете захватить это и получить причину.

другие функции также доступны.

можно использовать ET для этого. ET-небольшая библиотека Java 8 для преобразования/перевода исключений.

С ET это выглядит так:

// Do this once
ExceptionTranslator et = ET.newConfiguration().done();

...

// if your method returns something
Function<String, Integer> f = (t) -> et.withReturningTranslation(() -> myMethod(t));

// if your method returns nothing
Consumer<String> c = (t) -> et.withTranslation(() -> myMethod(t));

ExceptionTranslator экземпляры потокобезопасны и могут совместно использоваться несколькими компонентами. Вы можете настроить более конкретные правила преобразования исключений (например,FooCheckedException -> BarRuntimeException), Если вам нравится. Если других правил нет, проверенные исключения автоматически преобразуются в RuntimeException.

(отказ от ответственности: я автор ET)

подлый бросок идиома позволяет в обход CheckedException лямбда-выражения. Упаковка a CheckedException на RuntimeException не подходит для строгой обработки ошибок.

его можно использовать как Consumer функция, используемая в коллекции Java.

вот простая и улучшенная версия стрела.

import static Throwing.rethrow;

@Test
public void testRethrow() {
    thrown.expect(IOException.class);
    thrown.expectMessage("i=3");

    Arrays.asList(1, 2, 3).forEach(rethrow(e -> {
        int i = e.intValue();
        if (i == 3) {
            throw new IOException("i=" + i);
        }
    }));
}

это просто wrappsбыл лямбда в rethrow. Это делает CheckedException генерация каких-либо Exception что было добавь свою лямбду.

public final class Throwing {
    private Throwing() {}

    @Nonnull
    public static <T> Consumer<T> rethrow(@Nonnull final ThrowingConsumer<T> consumer) {
        return consumer;
    }

    /**
     * The compiler sees the signature with the throws T inferred to a RuntimeException type, so it
     * allows the unchecked exception to propagate.
     * 
     * http://www.baeldung.com/java-sneaky-throws
     */
    @SuppressWarnings("unchecked")
    @Nonnull
    public static <E extends Throwable> void sneakyThrow(@Nonnull Throwable ex) throws E {
        throw (E) ex;
    }

}

найти полный код и модульные тесты здесь.

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

Throws предложение в FunctionalInterface не является хорошей идеей

Я думаю, что это, вероятно, не очень хорошая идея для обеспечения бросков IOException из-за следующих причин

• это выглядит для меня как анти-шаблон для Stream/Lambda. Вся идея заключается в том, что вызывающий абонент решит, какой код предоставить и как обрабатывать исключение. Во многих случаях исключение IOException может быть неприменимо к клиенту. Например, если клиент получает значение из кэша/памяти вместо выполнения фактического ввода-вывода.

• кроме того, обработка исключений в потоках становится ужасной. Например, вот мой код будет выглядеть так, если я использую ваш API

             acceptMyMethod(s -> {
                  try {
                      Integer i = doSomeOperation(s);
                      return i;
                  } catch (IOException e) {
                      // try catch block because of throws clause
                      // in functional method, even though doSomeOperation
                      // might not be throwing any exception at all.
                      e.printStackTrace();
                  }
                  return null;
              });
  

  некрасиво, не так ли? Более того, как я упоминалось в моем первом пункте, что метод doSomeOperation может или не может бросать IOException (в зависимости от реализации клиента/вызывающего абонента), но из-за предложения throws в вашем методе FunctionalInterface мне всегда приходится писать try-catch.

что мне делать, если я действительно знаю, что этот API бросает IOException

• тогда, вероятно, мы путаем FunctionalInterface с типичными интерфейсами. Если вы знаете этот API бросит IOException, тогда, скорее всего, вы также знаете некоторое поведение по умолчанию/абстрактное поведение. Я думаю, вы должны определить интерфейс и развернуть свою библиотеку (с реализацией по умолчанию/абстрактной) следующим образом

  public interface MyAmazingAPI {
      Integer myMethod(String s) throws IOException;
  }
  

  но проблема try-catch все еще существует для клиента. Если я использую ваш API в потоке, мне все равно нужно обработать IOException в отвратительном блоке try-catch.

• предоставьте API, дружественный к потоку по умолчанию, как следует

  public interface MyAmazingAPI {
      Integer myMethod(String s) throws IOException;
  
      default Optional<Integer> myMethod(String s, Consumer<? super Exception> exceptionConsumer) {
          try {
              return Optional.ofNullable(this.myMethod(s));
          } catch (Exception e) {
              if (exceptionConsumer != null) {
                  exceptionConsumer.accept(e);
              } else {
                  e.printStackTrace();
              }
          }
  
          return Optional.empty();
      }
  }
  

  метод по умолчанию принимает объект consumer в качестве аргумента, который будет отвечать за обработку исключения. Теперь, с точки зрения клиента, код будет выглядеть следующим образом

  strStream.map(str -> amazingAPIs.myMethod(str, Exception::printStackTrace))
                  .filter(Optional::isPresent)
                  .map(Optional::get).collect(toList());
  

  мило, да? Конечно, вместо Exception::printStackTrace можно использовать logger или другую логику обработки.

• вы также можете предоставить метод, подобный https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html#exceptionally-java.util.function.Function- . Это означает, что вы можете предоставить другой метод, который будет содержать исключение из предыдущего вызова метода. Недостатком является то, что теперь вы делаете свой APIs stateful, что означает, что вам нужно обрабатывать потокобезопасность и которая в конечном итоге станет хитом производительности. Просто вариант для рассмотрения.

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

определение

CheckedValueSupplier

public static interface CheckedValueSupplier<V> {
    public V get () throws Exception;
}

CheckedValue

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();

что происходит?

добавления "бросает исключение " для каждого функционального интерфейса в JDK будет нарушать сухой принцип самым отвратительным образом. Чтобы избежать этого, создается один функциональный интерфейс, который выдает проверенное исключение (CheckedValueSupplier). Это будет единственный функциональный интерфейс, который позволяет проверять исключения. Все остальные функциональные интерфейсы будут использовать CheckedValueSupplier обернуть любой код, который выдает проверенное исключение.

на 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

нагнетать

кроме того, вы всегда можете перейти на RuntimeException. Существуют и другие ответы, которые охватывают эскалацию проверенного исключения из Consumer.

не потребляют.

как раз избегите функциональных интерфейсов всех совместно и используйте хорош-Оле-фасонированный для петли.

по умолчанию Java 8 функции не позволяет выбрасывать исключение, и, как предлагается в нескольких ответах, есть много способов его достичь, один из способов:

@FunctionalInterface
public interface FunctionWithException<T, R, E extends Exception> {
    R apply(T t) throws E;
}

определить как:

private FunctionWithException<String, Integer, IOException> myMethod = (str) -> {
    if ("abc".equals(str)) {
        throw new IOException();
    }
  return 1;
};

и добавить throws или try/catch то же исключение в методе вызывающего абонента.

Если вы не возражаете использовать стороннюю библиотеку, с Циклоп-реагировать, библиотека, в которую я вношу свой вклад, вы можете использовать FluentFunctions API для записи

 Function<String, Integer> standardFn = FluentFunctions.ofChecked(this::myMethod);

ofChecked принимает Jooλ CheckedFunction и возвращает ссылку, смягченную до стандартного (непроверенного) JDK java.утиль.функция.Функция.

в качестве альтернативы вы можете продолжать работать с захваченной функцией через api FluentFunctions!

например, чтобы выполнить свой метод, повторяя его до 5 раз и регистрируя его статус, вы можете написать

  FluentFunctions.ofChecked(this::myMethod)
                 .log(s->log.debug(s),e->log.error(e,e.getMessage())
                 .try(5,1000)
                 .apply("my param");

то, что я делаю, это позволить пользователю дать значение, которое он действительно хочет в случае исключения . Итак, у меня есть что-то похожее на это

public static <T, R> Function<? super T, ? extends R> defaultIfThrows(FunctionThatThrows<? super T, ? extends R> delegate, R defaultValue) {
    return x -> {
        try {
            return delegate.apply(x);
        } catch (Throwable throwable) {
            return defaultValue;
        }
    };
}

@FunctionalInterface
public interface FunctionThatThrows<T, R> {
    R apply(T t) throws Throwable;
}

и это можно назвать как :

defaultIfThrows(child -> child.getID(), null)

некоторые из предлагаемых решений используют общий аргумент E для передачи типа исключения, которое генерируется.

сделайте этот шаг дальше и вместо того, чтобы передавать тип исключения, передайте потребителю типа исключения, как в...

Consumer<E extends Exception>

Вы можете создать несколько повторно используемых вариации Consumer<Exception> который будет охватывать общие потребности обработки исключений вашего приложения.

Я сделаю что-то общее:

public interface Lambda {

    @FunctionalInterface
    public interface CheckedFunction<T> {

        T get() throws Exception;
    }

    public static <T> T handle(CheckedFunction<T> supplier) {
        try {
            return supplier.get();
        } catch (Exception exception) {
            throw new RuntimeException(exception);

        }
    }
}

использование:

 Lambda.handle(() -> method());

использовать Jool Library или скажем jOOλ library С JOOQ. Он не только предоставляет непроверенные интерфейсы обработки исключений, но и предоставляет класс Seq с множеством полезных методов.

также, он содержит функциональные интерфейсы с до 16 параметрами. Кроме того, он предоставляет класс кортежа, который используется в разных сценариях.

Jool Git Link

в частности, в поиске библиотека . Он содержит все интерфейсы от Java-8 с проверенным добавленный. См. ниже Для справки: -

public void frankTest() {
    int pageId= -1;

    List<Book> users= null;
    try {
        //Does Not Compile:  Object page=DatabaseConnection.getSpringConnection().queryForObject("SELECT * FROM bookmark_page", (rw, n) -> new Portal(rw.getInt("id"), "", users.parallelStream().filter(uu -> uu.getVbid() == rw.getString("user_id")).findFirst().get(), rw.getString("name")));

        //Compiles:
        Object page= DatabaseConnection.getSpringConnection().queryForObject("SELECT * FROM bookmark_page", (rw, n) -> { 
            try {
                final Book bk= users.stream().filter(bp -> { 
                    String name= null;
                    try {
                        name = rw.getString("name");
                    } catch (Exception e) {
                        // TODO Auto-generated catch block
                        e.printStackTrace();
                    }
                    return bp.getTitle().equals(name); 
                }).limit(1).collect(Collectors.toList()).get(0);
            } catch (Exception e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
            return new Portal(rw.getInt("id"), "", users.get(0), rw.getString("name")); 
        } );
    } catch (Exception e) {
        // TODO Auto-generated catch block
        e.printStackTrace();
    }
}