Java 8 Lambdas および Streams 内でチェック例外を効果的に処理するにはどうすればよいですか?

Java 8 ラムダとストリームからのチェック済み例外のスロー: 課題と回避策

Java 8 では、ラムダ式とストリームはエレガントで機能的なメソッドを提供します。データを操作する方法。ただし、これらの構造内からチェック例外をスローしようとすると、共通の課題が発生します。

問題: 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 コンパイラは、ラムダ内でのチェック例外の使用を禁止しています。

例外を実行時例外でラップしない理由

一般的な回避策の 1 つは、チェック例外を実行時例外でラップし、代わりにラップされた例外をスローします。ただし、このアプローチは、元の例外タイプがわかりにくくなり、コードベースに不必要な複雑さが追加されるため、望ましくありません。

API のバグ: 転送メカニズムの欠如

根本原因この課題の原因は、Java 8 API 設計の欠陥にあります。ストリームで使用される機能インターフェイスには、チェックされた例外を転送するメカニズムがありません。その結果、コンパイラは、ラムダ式によってスローされた例外の型を推論して、ストリーム パイプラインを通じて伝播することができません。

言語仕様のバグ: 不完全な型推論

もう 1 つの要因は、Java 言語仕様の微妙な欠陥です。型推論メカニズムでは、throws 句で使用される場合、型パラメータが型のリストを推論することはできません。その結果、コンパイラはラムダ式によってスローされた特定の例外タイプを推論できません。

現在の回避策と未解決の課題

Oracle はまだこれらの問題に直接対処していません。 、いくつかの回避策が存在します:

• try-catch ブロックを使用する: ラムダ内に try-catch ブロックを追加して、チェックされた例外をキャッチし、実行時例外として再スローします。
• カスタム例外ラッパー: チェックされた例外タイプを継承するカスタム例外ラッパーを作成し、getMessage() メソッドをオーバーライドして元の例外を保持しますmessage.
• 代替例外処理: 非同期操作のためのより堅牢な例外処理メカニズムを提供する java.util.concurrent.CompletableFuture クラスの使用を検討してください。

ただし、これらの回避策では、コードベースに追加のオーバーヘッドと複雑さが生じます。適切な例外転送メカニズムの欠如は、Java 8 ラムダ式およびストリームでチェック例外を操作する際の重大な制限として残ります。

以上がJava 8 Lambdas および Streams 内でチェック例外を効果的に処理するにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。