ChatGPT解决这个技术问题 Extra ChatGPT

如何从 Java 8 流中抛出 CHECKED 异常?

如何从 Java 8 流/lambda 中抛出 CHECKED 异常?

换句话说,我想让这样的代码编译:

public List<Class> getClasses() throws ClassNotFoundException {     

    List<Class> classes = 
        Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
              .map(className -> Class.forName(className))
              .collect(Collectors.toList());                  
    return classes;
    }

此代码无法编译,因为上面的 Class.forName() 方法会抛出 ClassNotFoundException,它已被检查。

请注意,我不想将检查的异常包装在运行时异常中,而是抛出包装的未经检查的异常。 我想自己抛出已检查的异常,并且不向流中添加丑陋的 try/catches


v
vladr

你的问题的简单答案是:你不能,至少不能直接。这不是你的错。甲骨文搞砸了。他们坚持检查异常的概念,但在设计功能接口、流、lambda 等时始终忘记处理检查异常。这对像 Robert C. Martin 这样的专家来说都是要点,他们将检查异常称为失败的实验。

在我看来,这是 API 中的一个巨大错误,也是语言规范中的一个小错误。

API 中的错误是它没有提供转发检查异常的工具,而这实际上对函数式编程非常有意义。正如我将在下面展示的那样,这样的设施很容易实现。

语言规范中的错误是它不允许类型参数推断类型列表而不是单个类型,只要类型参数仅在允许类型列表的情况下使用(throws 子句) .

作为 Java 程序员,我们的期望是应该编译以下代码:

import java.util.ArrayList;
import java.util.List;
import java.util.stream.Stream;

public class CheckedStream {
    // List variant to demonstrate what we actually had before refactoring.
    public List<Class> getClasses(final List<String> names) throws ClassNotFoundException {
        final List<Class> classes = new ArrayList<>();
        for (final String name : names)
            classes.add(Class.forName(name));
        return classes;
    }

    // The Stream function which we want to compile.
    public Stream<Class> getClasses(final Stream<String> names) throws ClassNotFoundException {
        return names.map(Class::forName);
    }
}

但是,它给出了:

cher@armor1:~/playground/Java/checkedStream$ javac CheckedStream.java 
CheckedStream.java:13: error: incompatible thrown types ClassNotFoundException in method reference
        return names.map(Class::forName);
                         ^
1 error

目前定义功能接口的方式会阻止编译器转发异常 - 没有声明会告诉 Stream.map() 如果 Function.apply() throws EStream.map() throws E 也是如此。

缺少的是用于传递检查异常的类型参数的声明。以下代码显示了如何使用当前语法实际声明此类传递类型参数。除了标记行中的特殊情况(这是下面讨论的限制)之外,此代码编译并按预期运行。

import java.io.IOException;
interface Function<T, R, E extends Throwable> {
    // Declare you throw E, whatever that is.
    R apply(T t) throws E;
}   

interface Stream<T> {
    // Pass through E, whatever mapper defined for E.
    <R, E extends Throwable> Stream<R> map(Function<? super T, ? extends R, E> mapper) throws E;
}   

class Main {
    public static void main(final String... args) throws ClassNotFoundException {
        final Stream<String> s = null;

        // Works: E is ClassNotFoundException.
        s.map(Class::forName);

        // Works: E is RuntimeException (probably).
        s.map(Main::convertClass);

        // Works: E is ClassNotFoundException.
        s.map(Main::throwSome);

        // Doesn't work: E is Exception.
        s.map(Main::throwSomeMore);  // error: unreported exception Exception; must be caught or declared to be thrown
    }   
    
    public static Class convertClass(final String s) {
        return Main.class;
    }   

    static class FooException extends ClassNotFoundException {}

    static class BarException extends ClassNotFoundException {}

    public static Class throwSome(final String s) throws FooException, BarException {
        throw new FooException();
    }   

    public static Class throwSomeMore(final String s) throws ClassNotFoundException, IOException  {
        throw new FooException();
    }   
}   

throwSomeMore 的情况下,我们希望看到 IOException 被遗漏,但它实际上遗漏了 Exception

这并不完美,因为类型推断似乎在寻找单一类型,即使在异常情况下也是如此。因为类型推断需要单一类型,所以 E 需要解析为 ClassNotFoundExceptionIOException 的公共 super,即 Exception

需要对类型推断的定义进行调整,以便如果在类型列表允许的情况下使用类型参数(throws 子句),编译器将查找多种类型。那么编译器报告的异常类型将与被引用方法的检查异常的原始 throws 声明一样具体,而不是单一的包罗万象的超类型。

坏消息是,这意味着甲骨文搞砸了。当然,它们不会破坏用户级代码,但是将异常类型参数引入现有的功能接口会破坏显式使用这些接口的所有用户级代码的编译。他们将不得不发明一些新的语法糖来解决这个问题。

更糟糕的消息是,Brian Goetz 在 2010 年已经讨论过这个话题(https://blogs.oracle.com/briangoetz/entry/exception_transparency_in_javahttp://mail.openjdk.java.net/pipermail/lambda-dev/2010-June/001484.html),但我被告知这项调查最终没有成功,而且我在甲骨文目前没有工作知道减轻检查异常和 lambdas 之间的交互。


有趣的。我相信有些人喜欢流允许更简单的并行代码,而另一些人则喜欢更简洁的代码。 Brian Goetz 显然更关心并行性(因为他撰写了 Java Concurrency in Practice),而 Robert Martin 更关心清洁代码(因为他撰写了 Clean Code 书)。样板的 try/catch 是为并行性付出的一个小代价,所以难怪 Brian Goetz 不会对在流中使用检查异常的问题感到震惊。也难怪罗伯特马丁讨厌检查异常,因为它们增加了混乱。
我预测,几年后,在流中处理受检异常的困难将导致以下两种结果之一:人们将停止使用受检异常,或者每个人都将开始使用一些类似于我在我的 UtilException 答案。我敢打赌,Java-8 流是受检异常棺材上的最后一颗钉子,并不是因为受检异常是 JDK 的一部分。尽管我喜欢并在业务代码中使用检查异常(对于某些特定用例),但我更喜欢所有常见的 JDK 异常扩展运行时。
@Unihedro问题仍然是功能接口不转发异常。我需要 lambda insidetry-catch 块,而这根本没有任何意义。只要在 lambda 中以某种方式使用 Class.forName,例如在 names.forEach(Class::forName) 中,问题就在那里。基本上,通过(糟糕!)设计,抛出检查异常的方法已被排除在直接作为函数接口参与函数编程之外。
@ChristianHujer“异常透明度”探索就是这样——一种探索(起源于 BGGA 提案)。经过更深入的分析,我们发现它在价值和复杂性之间的平衡很差,并且存在一些严重的问题(导致无法确定的推理问题,以及“catch X”不可靠等)。看起来很有希望——甚至是“显而易见的”——但经过更深入的探索,结果证明是有缺陷的。这是其中之一。
@BrianGoetz 是否有一些关于您提到的无法确定的推理问题的公开信息?我很好奇并想了解它。
M
MarcG

LambdaExceptionUtil 帮助程序类允许您在 Java 流中使用任何已检查的异常,如下所示:

Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
      .map(rethrowFunction(Class::forName))
      .collect(Collectors.toList());

注意 Class::forName 抛出 ClassNotFoundException,这是选中。流本身也抛出 ClassNotFoundException,而不是一些包装未经检查的异常。

public final class LambdaExceptionUtil {

@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; }

}

关于如何使用它的许多其他示例(在静态导入 LambdaExceptionUtil 之后):

@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");
    }    

截至 2015 年 11 月的更新 在@PaoloC please check his answer below and upvote it 的帮助下,代码已得到改进。他帮助解决了最后一个问题:现在编译器会要求您添加 throw 子句,一切就好像您可以在 Java 8 流上本地抛出已检查异常一样。

注意 1 上面 LambdaExceptionUtil 类的 rethrow 方法可以毫无顾忌地使用,并且可以在任何情况下使用

注意 2: 上面 LambdaExceptionUtil 类的 uncheck 方法是额外的方法,如果您不想使用它们,可以安全地将它们从类中删除。如果您确实使用过它们,请谨慎使用,而不是在了解以下用例、优点/缺点和限制之前:

• 如果您调用的方法实际上永远不会抛出它声明的异常,则可以使用uncheck 方法。例如:new String(byteArr, "UTF-8") 抛出 UnsupportedEncodingException,但 Java 规范保证 UTF-8 始终存在。在这里, throws 声明很麻烦,欢迎使用任何使用最少样板来使其静音的解决方案:String text = uncheck(() -> new String(byteArr, "UTF-8"));

• 如果您正在实现一个严格的接口,而您没有添加 throws 声明的选项,那么您可以使用 uncheck 方法,但抛出异常是完全合适的。包装一个异常只是为了获得抛出它的特权会导致一个带有虚假异常的堆栈跟踪,这些异常不会提供有关实际错误的信息。一个很好的例子是 Runnable.run(),它不会抛出任何已检查的异常。

• 在任何情况下,如果您决定使用 uncheck 方法,请注意在没有 throws 子句的情况下抛出 CHECKED 异常的两种后果:1) 调用代码将无法通过名称捕获它(如果您try,编译器会说:异常不会在相应的 try 语句体中抛出)。它会冒泡,并且可能会被一些“catch Exception”或“catch Throwable”捕获在主程序循环中,这可能是你想要的。 2)它违反了最小意外原则:捕获RuntimeException将不再足以保证捕获所有可能的异常。出于这个原因,我认为这不应该在框架代码中完成,而只能在您完全控制的业务代码中完成。

参考:

http://www.philandstuff.com/2012/04/28/sneakily-throwing-checked-exceptions.html

http://www.mail-archive.com/javaposse@googlegroups.com/msg05984.html

Lombok 项目注解:@SneakyThrows

Brian Goetz 的观点(反对)在这里:如何从 Java 8 流中抛出 CHECKED 异常?

https://softwareengineering.stackexchange.com/questions/225931/workaround-for-java-checked-exceptions?newreg=ddf0dd15e8174af8ba52e091cf85688e *


我觉得这个答案被不公正地否决了。该代码有效。应该抛出或处理已检查的异常。如果要抛出它们,只需在包含流的方法中保留“抛出子句”即可。但是如果你想通过简单的包装和重新抛出来处理它们,我想我更喜欢使用上面的代码来“解开”异常并让它们自己冒泡。我知道的唯一区别是冒泡异常不会扩展 RuntimeException。我知道纯粹主义者不会喜欢这样,但这会“不可避免地回来咬人”吗?似乎不太可能。
@Christian Hujer,老实说,在我添加“优点、缺点和限制”解释之前,他对以前的版本投了反对票。所以也许在当时是应得的。你不能教别人如何打破规则,至少要尝试理解和解释后果。我发布此问题的主要原因是为了获得有关我的答案缺点的反馈。我最终不是在这里得到这个反馈,而是来自programmers.stackexchange 中的另一个问题。然后我回到这里并更新了我的答案。
@Unihedro 但为什么它变得无法维护?我不明白为什么。有什么例子吗?
在我看来,@SuppressWarnings ("unchecked") 编译器的诡计是完全不能接受的。
@PaoloC:很抱歉我花了这么多时间来审查这个。我已经相应地更新了我的答案。我相信现在即使是 Brian Goetz 对“破坏类型系统”的抱怨也不再适用。
P
PaoloC

你可以!

扩展 @marcg 的 UtilException 并在必要时添加 throw E:这样,编译器会要求您添加 throw 子句,一切就好像您可以抛出已检查的异常本机 em> 在 java 8 的流上。

说明:只需将 LambdaExceptionUtil 复制/粘贴到您的 IDE 中,然后使用它,如下面的 LambdaExceptionUtilTest 所示。

public final class LambdaExceptionUtil {

    @FunctionalInterface
    public interface Consumer_WithExceptions<T, E extends Exception> {
        void accept(T t) throws E;
    }

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

    /**
     * .forEach(rethrowConsumer(name -> System.out.println(Class.forName(name))));
     */
    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) {
                throwActualException(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) {
                throwActualException(exception);
                return null;
            }
        };
    }

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

}

一些测试以显示用法和行为:

public class LambdaExceptionUtilTest {

    @Test(expected = MyTestException.class)
    public void testConsumer() throws MyTestException {
        Stream.of((String)null).forEach(rethrowConsumer(s -> checkValue(s)));
    }

    private void checkValue(String value) throws MyTestException {
        if(value==null) {
            throw new MyTestException();
        }
    }

    private class MyTestException extends Exception { }

    @Test
    public void testConsumerRaisingExceptionInTheMiddle() {
        MyLongAccumulator accumulator = new MyLongAccumulator();
        try {
            Stream.of(2L, 3L, 4L, null, 5L).forEach(rethrowConsumer(s -> accumulator.add(s)));
            fail();
        } catch (MyTestException e) {
            assertEquals(9L, accumulator.acc);
        }
    }

    private class MyLongAccumulator {
        private long acc = 0;
        public void add(Long value) throws MyTestException {
            if(value==null) {
                throw new MyTestException();
            }
            acc += value;
        }
    }

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

    @Test(expected = MyTestException.class)
    public void testFunctionRaisingException() throws MyTestException {
        Stream.of("ciao", null, "hello").<Integer>map(rethrowFunction(s -> transform(s))).collect(toList());
    }

}

抱歉 @setheron 你是对的,只需在 map 之前添加 <Integer>。事实上,java 编译器无法推断 Integer 返回类型。其他一切都应该是正确的。
这对我有用。通过强制处理异常,它使 MarcG 的答案变得完美。
上述问题的解决方案:像这样声明变量 Consumer 表达式 = rethrowConsumer((ThingType thing) -> thing.clone());然后在内部 foreach 中使用该表达式。
@Skychan:由于在这个修改后的新版本中你不再抑制任何异常,推理系统可能有点困难。在下面的一些评论中,Brian Goetz 谈到了导致“无法确定的推理问题”的“异常透明度”。
非常好。唯一不幸的是,它不能与抛出多个检查异常的方法完美配合。在这种情况下,编译器会让您捕获一个常见的超类型,例如 Exception
B
Brian Goetz

你不能安全地做到这一点。你可以作弊,但是你的程序坏了,这不可避免地会回来咬人(应该是你,但我们的作弊经常会炸毁别人。)

这是一种更安全的方法(但我仍然不推荐这样做。)

class WrappedException extends RuntimeException {
    Throwable cause;

    WrappedException(Throwable cause) { this.cause = cause; }
}

static WrappedException throwWrapped(Throwable t) {
    throw new WrappedException(t);
}

try 
    source.stream()
          .filter(e -> { ... try { ... } catch (IOException e) { throwWrapped(e); } ... })
          ...
}
catch (WrappedException w) {
    throw (IOException) w.cause;
}

在这里,您所做的是捕获 lambda 中的异常,从流管道中抛出一个表明计算异常失败的信号,捕获该信号,并对该信号进行操作以抛出底层异常。关键是您总是在捕获合成异常,而不是在不声明抛出该异常的情况下允许检查的异常泄漏。


就一个问题;导致 lambda 无法将已检查异常传播到其上下文之外的设计决策是什么?请注意,我确实理解 Function 等功能接口没有 throws 任何东西;我只是好奇。
throw w.cause; 不会让编译器抱怨该方法不抛出也不捕获 Throwable?因此,那里可能需要对 IOException 进行强制转换。此外,如果 lambda 抛出不止一种类型的检查异常,catch 的主体会变得有些丑陋,通过一些 instanceof 检查(或其他具有类似目的的东西)来验证抛出了哪个检查异常。
@schatten 一个原因是您可能会忘记捕获 WE,然后会泄漏一个奇怪的异常(没人知道如何处理)。 (你可能会说“但你捕获了异常,所以它是安全的。”在这个玩具示例中。但每次我看到代码库采用这种方法时,最终都会有人忘记。忽略异常的诱惑是无限的。)另一个风险是安全地使用它是特定于特定(使用站点,异常)组合的。它不能很好地扩展到多个异常或非同源用途。
@hoodaticus 我同意你的看法。话虽如此,您更喜欢包装更多(如上所示,增加“忘记”的风险)还是只创建 4 个巧妙的接口并使用不带包装的 lambda,如 stackoverflow.com/a/30974991/2365724 所示?谢谢
坦率地说,这个解决方案是完全行不通的。我认为流的目的是减少样板,而不是增加它。
R
Robert Važan

只需使用 NoException(我的项目)、jOOλ's Uncheckedthrowing-lambdasThrowable interfacesFaux Pas 中的任何一个。

// NoException
stream.map(Exceptions.sneak().function(Class::forName));

// jOOλ
stream.map(Unchecked.function(Class::forName));

// throwing-lambdas
stream.map(Throwing.function(Class::forName).sneakyThrow());

// Throwable interfaces
stream.map(FunctionWithThrowable.aFunctionThatUnsafelyThrowsUnchecked(Class::forName));

// Faux Pas
stream.map(FauxPas.throwingFunction(Class::forName));

J
Jeffrey

我编写了 a library,它扩展了 Stream API 以允许您抛出已检查的异常。它使用了 Brian Goetz 的技巧。

你的代码会变成

public List<Class> getClasses() throws ClassNotFoundException {     
    Stream<String> classNames = 
        Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String");

    return ThrowingStream.of(classNames, ClassNotFoundException.class)
               .map(Class::forName)
               .collect(Collectors.toList());
}

R
Radoslav Stoyanov

这个答案类似于 17,但避免了包装异常定义:

List test = new ArrayList();
        try {
            test.forEach(obj -> {

                //let say some functionality throws an exception
                try {
                    throw new IOException("test");
                }
                catch(Exception e) {
                    throw new RuntimeException(e);
                }
            });
        }
        catch (RuntimeException re) {
            if(re.getCause() instanceof IOException) {
                //do your logic for catching checked
            }
            else 
                throw re; // it might be that there is real runtime exception
        }

这正是 Op 不想要的:尝试 lambda 中的块。此外,只要在 try 块之外没有其他代码将 IOException 包装在 RuntimeException 中,它就只能按预期工作。为避免这种情况,可以使用自定义包装器运行时异常(定义为私有内部类)。
f
fge

你不能。

但是,您可能希望查看 one of my projects,它可以让您更轻松地操作此类“抛出 lambda”。

在您的情况下,您可以这样做:

import static com.github.fge.lambdas.functions.Functions.wrap;

final ThrowingFunction<String, Class<?>> f = wrap(Class::forName);

List<Class> classes =
    Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
          .map(f.orThrow(MyException.class))
          .collect(Collectors.toList());

并抓住 MyException

这是一个例子。另一个示例是您可以 .orReturn() 一些默认值。

请注意,这仍然是一项正在进行的工作,还有更多工作要做。更好的名称,更多的功能等。


但是,如果你想抛出原始的检查异常,你将不得不在流周围添加 try/catch 来解开它,这仍然很糟糕!我喜欢这样的想法,即您可以根据需要抛出未经检查的异常,并且可以根据需要向流返回默认值,但我也认为您应该在项目中添加一些 .orThrowChecked() 方法以允许检查异常本身被抛出。请查看我在此页面中的 UtilException 答案,看看您是否喜欢将这第三种可能性添加到您的项目中的想法。
“但是,如果你想抛出原始的检查异常,你将不得不在流周围添加 try/catch 来解开它,这仍然很糟糕!” <-- 是的,但你别无选择。 Lambdas 不能在其上下文之外传播已检查的异常,这是一个设计“决定”(我个人认为这是一个缺陷,但是哦)
至于你的想法,我不太了解它的作用,抱歉;毕竟你仍然不加控制地抛出,所以这和我做的有什么不同? (除了我有不同的界面)
无论如何,欢迎您为该项目做出贡献!另外,您是否注意到 Stream 实现了 AutoCloseable
让我问您:您上面的 MyException 是否需要是未经检查的异常?
s
sergut

TL;DR 只需使用 Lombok 的 @SneakyThrows

Christian Hujer 已经详细解释了为什么从流中抛出已检查的异常,严格来说,由于 Java 的限制是不可能的。

其他一些答案解释了绕过语言限制的技巧,但仍然能够满足抛出“已检查异常本身,并且不向流中添加丑陋的 try/catch”的要求,其中一些需要额外的数十行样板。

我将强调另一个选项,即恕我直言,它比所有其他选项都干净得多:Lombok 的 @SneakyThrows。其他答案顺便提到了它,但在许多不必要的细节下有点被掩盖了。

生成的代码很简单:

public List<Class> getClasses() throws ClassNotFoundException {
    List<Class> classes =
        Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
                .map(className -> getClass(className))
                .collect(Collectors.toList());
    return classes;
}

@SneakyThrows                                 // <= this is the only new code
private Class<?> getClass(String className) {
    return Class.forName(className);
}

我们只需要一个 Extract Method 重构(由 IDE 完成)和 @SneakyThrows一个 附加行。注释负责添加所有样板文件,以确保您可以抛出已检查的异常,而无需将其包装在 RuntimeException 中并且无需显式声明它。


不鼓励使用 lombok。
@Dragas 设计一种语言的方式应该不鼓励人们认为需要提出像 Lombok 这样的东西;)
是的。你有能力以任何你想要的方式定义事物,转动所有的旋钮,甚至添加你自己的。但是相反,您选择将其全部扔掉,因为这些混乱会侵入编译器并生成一些无法读取的隐式垃圾,除非您阅读了一些有关 lombok 的内部结构以及它生成事物的模式是什么。不,工具应该不鼓励像 lombok 那样支持生成代码。至少那时我不需要一些 IDE 插件来查看所有你懒得用同一个 IDE 生成的 getter。
i
introspected

总结上面的高级解决方案的评论是使用一个特殊的包装器来处理未经检查的函数,以及像 API 这样的构建器,它提供恢复、重新抛出和抑制。

Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
          .map(Try.<String, Class<?>>safe(Class::forName)
                  .handle(System.out::println)
                  .unsafe())
          .collect(toList());

下面的代码演示了消费者、供应商和函数接口。它可以很容易地扩展。此示例中删除了一些公共关键字。

Try 类是客户端代码的端点。安全方法可能对每个函数类型都有唯一的名称。 CheckedConsumer、CheckedSupplier 和 CheckedFunction 是经过检查的 lib 函数类似物,可以独立于 Try 使用

CheckedBuilder 是一些检查函数中处理异常的接口。 orTry 允许在先前失败时执行另一个相同类型的函数。 handle 提供异常处理,包括异常类型过滤。处理程序的顺序很重要。减少不安全的方法并重新抛出执行链中的最后一个异常。如果所有函数都失败,reduce 方法 orElse 和 orElseGet 会返回类似于 Optional 的替代值。还有方法抑制。 CheckedWrapper 是 CheckedBuilder 的常见实现。

final class Try {

    public static <T> CheckedBuilder<Supplier<T>, CheckedSupplier<T>, T> 
        safe(CheckedSupplier<T> supplier) {
        return new CheckedWrapper<>(supplier, 
                (current, next, handler, orResult) -> () -> {
            try { return current.get(); } catch (Exception ex) {
                handler.accept(ex);
                return next.isPresent() ? next.get().get() : orResult.apply(ex);
            }
        });
    }

    public static <T> Supplier<T> unsafe(CheckedSupplier<T> supplier) {
        return supplier;
    }

    public static <T> CheckedBuilder<Consumer<T>, CheckedConsumer<T>, Void> 
        safe(CheckedConsumer<T> consumer) {
        return new CheckedWrapper<>(consumer, 
                (current, next, handler, orResult) -> t -> {
            try { current.accept(t); } catch (Exception ex) {
                handler.accept(ex);
                if (next.isPresent()) {
                    next.get().accept(t);
                } else {
                    orResult.apply(ex);
                }
            }
        });
    }

    public static <T> Consumer<T> unsafe(CheckedConsumer<T> consumer) {
        return consumer;
    }

    public static <T, R> CheckedBuilder<Function<T, R>, CheckedFunction<T, R>, R> 
        safe(CheckedFunction<T, R> function) {
        return new CheckedWrapper<>(function, 
                (current, next, handler, orResult) -> t -> {
            try { return current.applyUnsafe(t); } catch (Exception ex) {
                handler.accept(ex);
                return next.isPresent() ? next.get().apply(t) : orResult.apply(ex);
            }
        });
    }

    public static <T, R> Function<T, R> unsafe(CheckedFunction<T, R> function) {
        return function;
    }

    @SuppressWarnings ("unchecked")
    static <T, E extends Throwable> T throwAsUnchecked(Throwable exception) throws E { 
        throw (E) exception; 
    }
}

@FunctionalInterface interface CheckedConsumer<T> extends Consumer<T> {
    void acceptUnsafe(T t) throws Exception;
    @Override default void accept(T t) {
        try { acceptUnsafe(t); } catch (Exception ex) {
            Try.throwAsUnchecked(ex);
        }
    }
}

@FunctionalInterface interface CheckedFunction<T, R> extends Function<T, R> {
    R applyUnsafe(T t) throws Exception;
    @Override default R apply(T t) {
        try { return applyUnsafe(t); } catch (Exception ex) {
            return Try.throwAsUnchecked(ex);
        }
    }
}

@FunctionalInterface interface CheckedSupplier<T> extends Supplier<T> {
    T getUnsafe() throws Exception;
    @Override default T get() {
        try { return getUnsafe(); } catch (Exception ex) {
            return Try.throwAsUnchecked(ex);
        }
    }
}

interface ReduceFunction<TSafe, TUnsafe, R> {
    TSafe wrap(TUnsafe current, Optional<TSafe> next, 
            Consumer<Throwable> handler, Function<Throwable, R> orResult);
}

interface CheckedBuilder<TSafe, TUnsafe, R> {
    CheckedBuilder<TSafe, TUnsafe, R> orTry(TUnsafe next);

    CheckedBuilder<TSafe, TUnsafe, R> handle(Consumer<Throwable> handler);

    <E extends Throwable> CheckedBuilder<TSafe, TUnsafe, R> handle(
            Class<E> exceptionType, Consumer<E> handler);

    CheckedBuilder<TSafe, TUnsafe, R> handleLast(Consumer<Throwable> handler);

    <E extends Throwable> CheckedBuilder<TSafe, TUnsafe, R> handleLast(
            Class<E> exceptionType, Consumer<? super E> handler);

    TSafe unsafe();
    TSafe rethrow(Function<Throwable, Exception> transformer);
    TSafe suppress();
    TSafe orElse(R value);
    TSafe orElseGet(Supplier<R> valueProvider);
}

final class CheckedWrapper<TSafe, TUnsafe, R> 
        implements CheckedBuilder<TSafe, TUnsafe, R> {

    private final TUnsafe function;
    private final ReduceFunction<TSafe, TUnsafe, R> reduceFunction;

    private final CheckedWrapper<TSafe, TUnsafe, R> root;
    private CheckedWrapper<TSafe, TUnsafe, R> next;

    private Consumer<Throwable> handlers = ex -> { };
    private Consumer<Throwable> lastHandlers = ex -> { };

    CheckedWrapper(TUnsafe function, 
            ReduceFunction<TSafe, TUnsafe, R> reduceFunction) {
        this.function = function;
        this.reduceFunction = reduceFunction;
        this.root = this;
    }

    private CheckedWrapper(TUnsafe function, 
            CheckedWrapper<TSafe, TUnsafe, R> prev) {
        this.function = function;
        this.reduceFunction = prev.reduceFunction;
        this.root = prev.root;
        prev.next = this;
    }

    @Override public CheckedBuilder<TSafe, TUnsafe, R> orTry(TUnsafe next) {
        return new CheckedWrapper<>(next, this);
    }

    @Override public CheckedBuilder<TSafe, TUnsafe, R> handle(
            Consumer<Throwable> handler) {
        handlers = handlers.andThen(handler);
        return this;
    }

    @Override public <E extends Throwable> CheckedBuilder<TSafe, TUnsafe, R> 
        handle(Class<E> exceptionType, Consumer<E> handler) {
        handlers = handlers.andThen(ex -> {
            if (exceptionType.isInstance(ex)) {
                handler.accept(exceptionType.cast(ex));
            }
        });
        return this;
    }

    @Override public CheckedBuilder<TSafe, TUnsafe, R> handleLast(
            Consumer<Throwable> handler) {
        lastHandlers = lastHandlers.andThen(handler);
        return this;
    }

    @Override public <E extends Throwable> CheckedBuilder<TSafe, TUnsafe, R> 
        handleLast(Class<E> exceptionType, Consumer<? super E> handler) {
        lastHandlers = lastHandlers.andThen(ex -> {
            if (exceptionType.isInstance(ex)) {
                handler.accept(exceptionType.cast(ex));
            }
        });
        return this;
    }

    @Override public TSafe unsafe() {
        return root.reduce(ex -> Try.throwAsUnchecked(ex));
    }

    @Override
    public TSafe rethrow(Function<Throwable, Exception> transformer) {
        return root.reduce(ex -> Try.throwAsUnchecked(transformer.apply(ex)));
    }

    @Override public TSafe suppress() {
        return root.reduce(ex -> null);
    }

    @Override public TSafe orElse(R value) {
        return root.reduce(ex -> value);
    }

    @Override public TSafe orElseGet(Supplier<R> valueProvider) {
        Objects.requireNonNull(valueProvider);
        return root.reduce(ex -> valueProvider.get());
    }

    private TSafe reduce(Function<Throwable, R> orResult) {
        return reduceFunction.wrap(function, 
                Optional.ofNullable(next).map(p -> p.reduce(orResult)), 
                this::handle, orResult);
    }

    private void handle(Throwable ex) {
        for (CheckedWrapper<TSafe, TUnsafe, R> current = this; 
                current != null; 
                current = current.next) {
            current.handlers.accept(ex);
        }
        lastHandlers.accept(ex);
    }
}

O
OSGI Java

这是原始问题的不同视图或解决方案。在这里,我展示了我们可以选择编写一个仅处理有效值子集的代码,并可以选择在引发异常时检测和处理案例。

    @Test
    public void getClasses() {

        String[] classNames = {"java.lang.Object", "java.lang.Integer", "java.lang.Foo"};
        List<Class> classes =
                Stream.of(classNames)
                        .map(className -> {
                            try {
                                return Class.forName(className);
                            } catch (ClassNotFoundException e) {
                                // log the error
                                return null;
                            }
                        })
                        .filter(c -> c != null)
                        .collect(Collectors.toList());

        if (classes.size() != classNames.length) {
            // add your error handling here if needed or process only the resulting list
            System.out.println("Did not process all class names");
        }

        classes.forEach(System.out::println);
    }

M
Mikhail Kholodkov

可能,更好和更实用的方法是包装异常并在流中进一步传播它们。以 VavrTry 类型为例。

例子:

interface CheckedFunction<I, O> {
    O apply(I i) throws Exception; }

static <I, O> Function<I, O> unchecked(CheckedFunction<I, O> f) {
    return i -> {
        try {
            return f.apply(i);
        } catch(Exception ex) {

            throw new RuntimeException(ex);
        }
    } }

fileNamesToRead.map(unchecked(file -> Files.readAllLines(file)))

或者

@SuppressWarnings("unchecked")
private static <T, E extends Exception> T throwUnchecked(Exception e) throws E {
    throw (E) e;
}

static <I, O> Function<I, O> unchecked(CheckedFunction<I, O> f) {
    return arg -> {
        try {
            return f.apply(arg);
        } catch(Exception ex) {
            return throwUnchecked(ex);
        }
    };
}

第二种实现避免将异常包装在 RuntimeException 中。 throwUnchecked 有效,因为几乎所有通用异常在 java 中都被视为未经检查。


P
Piotr Niewinski

您还可以编写包装器方法来包装未经检查的异常,甚至使用表示另一个功能接口(具有相同的返回类型 R)的附加参数来增强包装器。在这种情况下,您可以传递一个函数,该函数将在出现异常时执行并返回。请参见下面的示例:

private void run() {
    List<String> list = Stream.of(1, 2, 3, 4).map(wrapper(i ->
            String.valueOf(++i / 0), i -> String.valueOf(++i))).collect(Collectors.toList());
    System.out.println(list.toString());
}

private <T, R, E extends Exception> Function<T, R> wrapper(ThrowingFunction<T, R, E> function, 
Function<T, R> onException) {
    return i -> {
        try {
            return function.apply(i);
        } catch (ArithmeticException e) {
            System.out.println("Exception: " + i);
            return onException.apply(i);
        } catch (Exception e) {
            System.out.println("Other: " + i);
            return onException.apply(i);
        }
    };
}

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

J
JohnnyO

我同意上面的评论,在使用 Stream.map 时,您仅限于实现不抛出异常的函数。

但是,您可以创建自己的 FunctionalInterface,如下所示。

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

然后使用 Lambda 或引用实现它,如下所示。

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

 }

}

M
Matt McHenry

处理 map 操作可能引发的已检查异常的唯一内置方法是将它们封装在 CompletableFuture 中。 (如果您不需要保留异常,Optional 是一个更简单的替代方案。)这些类旨在允许您以函数方式表示条件操作。

需要几个重要的辅助方法,但您可以得到相对简洁的代码,同时仍然清楚地表明您的流的结果取决于 map 操作是否成功完成。这是它的样子:

    CompletableFuture<List<Class<?>>> classes =
            Stream.of("java.lang.String", "java.lang.Integer", "java.lang.Double")
                  .map(MonadUtils.applyOrDie(Class::forName))
                  .map(cfc -> cfc.thenApply(Class::getSuperclass))
                  .collect(MonadUtils.cfCollector(ArrayList::new,
                                                  List::add,
                                                  (List<Class<?>> l1, List<Class<?>> l2) -> { l1.addAll(l2); return l1; },
                                                  x -> x));
    classes.thenAccept(System.out::println)
           .exceptionally(t -> { System.out.println("unable to get class: " + t); return null; });

这会产生以下输出:

[class java.lang.Object, class java.lang.Number, class java.lang.Number]

applyOrDie 方法采用引发异常的 Function,并将其转换为返回已完成的 CompletableFutureFunction - 要么使用原始函数的结果正常完成,要么异常完成并引发异常.

第二个 map 操作说明您现在有一个 Stream<CompletableFuture<T>> 而不仅仅是一个 Stream<T>CompletableFuture 仅在上游操作成功时才执行此操作。 API 使这一点变得明确,但相对轻松。

直到你进入 collect 阶段,就是这样。这是我们需要一个非常重要的辅助方法的地方。我们想在 CompletableFuture“内部”“提升”一个正常的收集操作(在本例中为 toList())——cfCollector() 允许我们使用 supplieraccumulatorcombinerfinisher 根本不需要了解有关 CompletableFuture 的任何信息。

帮助方法可以在 GitHub 上我的 MonadUtils 类中找到,这仍然是一项正在进行的工作。


C
Colin D Bennett

我使用这种包装异常:

public class CheckedExceptionWrapper extends RuntimeException {
    ...
    public <T extends Exception> CheckedExceptionWrapper rethrow() throws T {
        throw (T) getCause();
    }
}

它将需要静态处理这些异常:

void method() throws IOException, ServletException {
    try { 
        list.stream().forEach(object -> {
            ...
            throw new CheckedExceptionWrapper(e);
            ...            
        });
    } catch (CheckedExceptionWrapper e){
        e.<IOException>rethrow();
        e.<ServletExcepion>rethrow();
    }
}

Try it online!

尽管在第一次 rethrow() 调用期间无论如何都会重新抛出异常(哦,Java 泛型...),但这种方式允许获得可能异常的严格静态定义(需要在 throws 中声明它们)。并且不需要 instanceof 或其他东西。


E
Eltan Hajiyev

您可以使用 apache commons-lang3 库来做到这一点。

https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/function/Failable.html

public List<Class> getClasses() throws ClassNotFoundException {
    List<Class> classes =
            Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String")
                    .map(Failable.asFunction(Class::forName))
                    .collect(Collectors.toList());
    return classes;
}

M
Matthias Ronge

我认为这种方法是正确的:

public List<Class> getClasses() throws ClassNotFoundException {
    List<Class> classes;
    try {
        classes = Stream.of("java.lang.Object", "java.lang.Integer", "java.lang.String").map(className -> {
            try {
                return Class.forName(className);
            } catch (ClassNotFoundException e) {
                throw new UndeclaredThrowableException(e);
            }
        }).collect(Collectors.toList());
    } catch (UndeclaredThrowableException e) {
        if (e.getCause() instanceof ClassNotFoundException) {
            throw (ClassNotFoundException) e.getCause();
        } else {
            // this should never happen
            throw new IllegalStateException(e.getMessage(), e);
        }
    }
    return classes;
}

将已检查的异常包装在 UndeclaredThrowableException 中的 Callable 中(这是此异常的用例),然后在外面解包。

是的,我觉得它很难看,我建议不要在这种情况下使用 lambda,而只是退回到一个好的旧循环,除非您正在使用并行流并且并行化带来了客观的好处,证明了代码的不可读性是合理的。

正如许多其他人所指出的那样,这种情况有一些解决方案,我希望其中的一个能成为 Java 的未来版本。


(1) 已经有几个答案显示了这样的示例,那么您的答案对尚未涵盖的问答添加了什么?像这样发布重复的答案只会给网站增加混乱。 (2) OP 明确表示他们不想这样做。 “请注意,我不想将检查的异常包装在运行时异常中,而是抛出包装的未经检查的异常。”