如何在 Java 8 Lambda 和 Streams 中有效处理受检异常？

从 Java 8 Lambda 和 Stream 抛出已检查异常：挑战和解决方法

在 Java 8 中，lambda 表达式和流提供了优雅且实用的方法操纵数据的方式。然而，当尝试从这些构造中抛出检查异常时，会出现一个常见的挑战。

问题：从 Lambda 抛出检查异常

问题源于缺乏从 lambda 表达式抛出已检查异常的直接方法。换句话说，lambda 不能直接在其 throws 子句中声明异常。考虑以下示例：

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() 方法抛出已检查异常，此代码无法编译。 Java 编译器禁止在 lambda 中使用已检查异常。

为什么不在运行时异常中包装异常？

一种常见的解决方法是将已检查异常包装在运行时异常中，而是抛出包装的异常。然而，这种方法是不可取的，因为它掩盖了原始异常类型，并给代码库增加了不必要的复杂性。

API Bug：缺乏转发机制

根本原因这一挑战的根源在于 Java 8 API 设计中的一个缺陷。流中使用的功能接口不提供转发已检查异常的机制。因此，编译器无法推断 lambda 表达式引发的异常类型并通过流管道传播它。

语言规范错误：不完整的类型推断

另一个影响因素是 Java 语言规范中的一个微妙缺陷。类型推断机制不允许类型参数在 throws 子句中使用时推断类型列表。因此，编译器无法推断 lambda 表达式抛出的特定异常类型。

当前的解决方法和开放挑战

虽然 Oracle 尚未直接解决这些问题，存在几种解决方法：

• 使用 try-catch 块：在 lambda 中添加 try-catch 块以捕获检查的异常并将其作为运行时异常重新抛出。
• 自定义异常包装器： 创建继承自已检查异常类型的自定义异常包装器并重写 getMessage() 方法以保留原始异常
• 替代异常处理： 考虑使用 java.util.concurrent.CompletableFuture 类，它为异步操作提供更强大的异常处理机制。

但是，这些解决方法给代码库带来了额外的开销和复杂性。在处理 Java 8 lambda 表达式和流中的检查异常时，缺乏适当的异常转发机制仍然是一个重大限制。

以上是如何在 Java 8 Lambda 和 Streams 中有效处理受检异常？的详细内容。更多信息请关注PHP中文网其他相关文章！