Я работаю над проектом с Java 8 и обнаружил одну ситуацию, которую я не могу понять.
Итак, мой вопрос, почему? Почему код компилируется для каждого цикла и не компилируется с лямбдой?
Ответ 2
Вы можете попробовать следующее:
void deleteEntity(Node node) throws SomeException { node.getChildren().forEach(UtilException.rethrowConsumer(this::deleteChild));
}
Ниже UtilException
вспомогательный класс UtilException
позволяет использовать любые проверенные исключения в потоках Java. Обратите внимание, что поток выше также выбрасывает исходное проверенное исключение, созданное this::deleteChild
, и NOT some this::deleteChild
unchecked exception.
public final class UtilException {
@FunctionalInterface
public interface Consumer_WithExceptions<T, E extends Exception> {
void accept(T t) throws E;
}
@FunctionalInterface
public interface BiConsumer_WithExceptions<T, U, E extends Exception> {
void accept(T t, U u) throws E;
}
@FunctionalInterface
public interface Function_WithExceptions<T, R, E extends Exception> {
R apply(T t) throws E;
}
@FunctionalInterface
public interface Supplier_WithExceptions<T, E extends Exception> {
T get() throws E;
}
@FunctionalInterface
public interface Runnable_WithExceptions<E extends Exception> {
void run() throws E;
}
/** .forEach(rethrowConsumer(name -> System.out.println(Class.forName(name)))); or .forEach(rethrowConsumer(ClassNameUtil::println)); */
public static <T, E extends Exception> Consumer<T> rethrowConsumer(Consumer_WithExceptions<T, E> consumer) throws E {
return t -> {
try { consumer.accept(t); }
catch (Exception exception) { throwAsUnchecked(exception); }
};
}
public static <T, U, E extends Exception> BiConsumer<T, U> rethrowBiConsumer(BiConsumer_WithExceptions<T, U, E> biConsumer) throws E {
return (t, u) -> {
try { biConsumer.accept(t, u); }
catch (Exception exception) { throwAsUnchecked(exception); }
};
}
/** .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) { throwAsUnchecked(exception); return null; }
};
}
/** rethrowSupplier(() -> new StringJoiner(new String(new byte[]{77, 97, 114, 107}, "UTF-8"))), */
public static <T, E extends Exception> Supplier<T> rethrowSupplier(Supplier_WithExceptions<T, E> function) throws E {
return () -> {
try { return function.get(); }
catch (Exception exception) { throwAsUnchecked(exception); return null; }
};
}
/** uncheck(() -> Class.forName("xxx")); */
public static void uncheck(Runnable_WithExceptions t)
{
try { t.run(); }
catch (Exception exception) { throwAsUnchecked(exception); }
}
/** uncheck(() -> Class.forName("xxx")); */
public static <R, E extends Exception> R uncheck(Supplier_WithExceptions<R, E> supplier)
{
try { return supplier.get(); }
catch (Exception exception) { throwAsUnchecked(exception); return null; }
}
/** uncheck(Class::forName, "xxx"); */
public static <T, R, E extends Exception> R uncheck(Function_WithExceptions<T, R, E> function, T t) {
try { return function.apply(t); }
catch (Exception exception) { throwAsUnchecked(exception); return null; }
}
@SuppressWarnings ("unchecked")
private static <E extends Throwable> void throwAsUnchecked(Exception exception) throws E { throw (E)exception; }
}
Многие другие примеры использования (после статического импорта UtilException
):
@Test
public void test_Consumer_with_checked_exceptions() throws IllegalAccessException {
Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
.forEach(rethrowConsumer(className -> System.out.println(Class.forName(className))));
Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
.forEach(rethrowConsumer(System.out::println));
}
@Test
public void test_Function_with_checked_exceptions() throws ClassNotFoundException {
List<Class> classes1
= Stream.of("Object", "Integer", "String")
.map(rethrowFunction(className -> Class.forName("java.lang." + className)))
.collect(Collectors.toList());
List<Class> classes2
= Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
.map(rethrowFunction(Class::forName))
.collect(Collectors.toList());
}
@Test
public void test_Supplier_with_checked_exceptions() throws ClassNotFoundException {
Collector.of(
rethrowSupplier(() -> new StringJoiner(new String(new byte[]{77, 97, 114, 107}, "UTF-8"))),
StringJoiner::add, StringJoiner::merge, StringJoiner::toString);
}
@Test
public void test_uncheck_exception_thrown_by_method() {
Class clazz1 = uncheck(() -> Class.forName("java.lang.String"));
Class clazz2 = uncheck(Class::forName, "java.lang.String");
}
@Test (expected = ClassNotFoundException.class)
public void test_if_correct_exception_is_still_thrown_by_method() {
Class clazz3 = uncheck(Class::forName, "INVALID");
}
Но не используйте его, прежде чем понимать следующие преимущества, недостатки и ограничения:
• Если вызывающий код обрабатывает исключенное исключение, вы ДОЛЖНЫ добавить его в предложение throws метода, содержащего поток. Компилятор не заставит вас добавлять его больше, поэтому его легче забыть.
• Если вызывающий код уже обрабатывает исключенное исключение, компилятор WILL напоминает вам добавить предложение throws в объявление метода, которое содержит поток (если вы этого не скажете: исключение никогда не бросается в тело соответствующего утверждения try).
• В любом случае вы не сможете окружить поток, чтобы поймать исключенное исключение. INSIDE метод, который содержит поток (если вы попытаетесь, компилятор скажет: "Исключение никогда не выбрасывается в тело соответствующей инструкции try").
• Если вы вызываете метод, который буквально никогда не может генерировать исключение, которое он объявляет, тогда вы не должны включать предложение throws. Например: new String (byteArr, "UTF-8") выдает UnsupportedEncodingException, но UTF-8 гарантируется спецификацией Java всегда присутствовать. Здесь объявление бросков является неприятным, и любое решение, чтобы заставить его замолчать с минимальным шаблоном, приветствуется.
• Если вы ненавидите проверенные исключения и чувствуете, что они никогда не должны быть добавлены к Java-языку для начала (все большее число людей думает так, и я НЕ являюсь одним из них), то просто не добавляйте проверенное исключение в бросает предложение метода, содержащего поток. Таким образом, проверенное исключение будет вести себя так же, как исключение Unchecked.
• Если вы внедряете строгий интерфейс, в котором у вас нет возможности добавить объявление бросков, и при этом исключение исключение вполне уместно, то обертывание исключения, чтобы получить привилегию бросать его, приводит к stacktrace с ложными исключениями которые не дают никакой информации о том, что на самом деле пошло не так. Хорошим примером является Runnable.run(), который не бросает никаких проверенных исключений. В этом случае вы можете не добавлять исключенное исключение в предложение throws метода, содержащего поток.
• В любом случае, если вы решите НЕ добавлять (или забывать добавить) исключенное исключение в предложение throws метода, содержащего поток, помните об этих двух последствиях бросания CHECKED исключений:
1) Код вызова не сможет поймать его по имени (если вы попытаетесь, компилятор скажет: "Исключение никогда не выбрасывается в тело соответствующей инструкции try"). Он будет пузыриться и, вероятно, попадет в основной программный цикл с помощью некоторых "исключений catch" или "catch Throwable", которые могут быть тем, что вы хотите в любом случае.
2) Это нарушает принцип наименьшего удивления: больше не хватит, чтобы поймать RuntimeException, чтобы гарантировать возможность обнаружения всех возможных исключений. По этой причине я считаю, что этого не следует делать в коде кода, но только в бизнес-коде, который вы полностью контролируете.
В заключение: я считаю, что ограничения здесь не являются серьезными, и класс UtilException
может использоваться без страха. Однако, это зависит от вас!