ある日、 id:cero-t がJJUGの重鎮たちと話している中で、とある宿題をもらいましたとさ。
「Java8のラムダの中で例外が発生したら、どうなるんだろう？」
こんにちは、アキバです。
もう皆さんはJava8を使ってみましたか？
とりあえずインストールしてみた人！
・・はーい (おまえか
という冗談はさておき、
今回は、id:cero-t に代わって私が冒頭のお題を調べてみました。
1. SerialStreamで動かしたラムダで例外が発生したら
まずは、小手調べにシングルスレッドの場合を見てみましょう。
検査例外が発生するようなコードをラムダに書いてみると、コンパイルエラーになります。
こんなコードです。
try (BufferedWriter writer = Files.newBufferedWriter(Paths.get(W_FILENAME))) { // writer.write() がIOExceptionをスローするので、catchしろと言われる lines.forEach(s -> writer.write(s + '\n')); } catch (IOException ioex) { System.out.println("IOException in Writer-try."); ioex.printStackTrace(System.out); throw new UncheckedIOException(ioex); }
そこで、ラムダの中で例外をハンドリングしてみると、確かにエラーが出なくなります。
こんなコードです。
try (BufferedWriter writer = Files.newBufferedWriter(Paths.get(W_FILENAME))) { lines.forEach(s -> { // ラムダの中で例外をcatchする try { writer.write(s + '\n'); } catch (IOException ex) { System.out.println("IOException in lambda."); ex.printStackTrace(System.out); throw new UncheckedIOException(ex); } }); } catch (IOException | RuntimeException ex) { System.out.println("Exception in Writer-try."); ex.printStackTrace(System.out); throw ex; }
動かしてみるとどうなるんでしょうね。
あ、今回は、writer.write()で例外を発生させるのも面倒なので、
writer.write(s + '\n');
を
throw new IOException("IOException in writer");
に変えて動かしています。
動かした結果、こうなりました。
IOException in lambda.
java.io.IOException: IOException in writer
at study.java8.lambda.StreamSample.lambda$streamExceptionSample1$0(StreamSample.java:68)
at study.java8.lambda.StreamSample$$Lambda$1/149928006.accept(Unknown Source)
at java.util.ArrayList.forEach(ArrayList.java:1234)
at study.java8.lambda.StreamSample.streamExceptionSample1(StreamSample.java:65)
at study.java8.lambda.StreamSample.main(StreamSample.java:33)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
Exception in Writer-try.
java.io.UncheckedIOException: java.io.IOException: IOException in writer
at study.java8.lambda.StreamSample.lambda$streamExceptionSample1$0(StreamSample.java:72)
at study.java8.lambda.StreamSample$$Lambda$1/149928006.accept(Unknown Source)
：
(略)
Caused by: java.io.IOException: IOException in writer
at study.java8.lambda.StreamSample.lambda$streamExceptionSample1$0(StreamSample.java:68)
... 9 more最初の行に出た例外のメッセージが「IOException in lambda.」となっていることから、ラムダ呼び出しの中で例外をcatchしていることがわかります。
次に、「Exception in Writer-try.」と出ています。
おぉ、ラムダ呼出しの外側で、ラムダがスローした例外をcatch出来ていますね。
UncheckedIOExceptionの中身は、ラムダ処理自体で発生した例外でした。
つまり、ラムダの中で検査例外が発生するようなコードは、
無名内部クラスと同じように例外をcatchして処理する必要があるということがわかりました。
ただし、無名内部クラスと大きく違うのは、メソッド定義ではないので、例外の宣言は出来ません。
よって、スロー出来るのは検査例外以外(RuntimeExceptionのサブクラスなど)でなくてはいけないということになりますね。
ふむふむ。
では、いよいよ本題です。
2. ParallelStreamで動かしたラムダで例外が発生したら
Parallelってことは、マルチスレッド動作なわけじゃないですか。
- 発生した例外は誰が受け取るのか？どこまで伝播するのか？
- 例外が発生したスレッド全てでcatch処理が行われるのか？
- 例外が発生しなかった他のスレッドはどのような影響を受けるのか？
- そもそもちゃんと全部のスレッド処理が終了するのか？
皆さんも気になりますよね？
私も気になります。
（だから、それが本題なんだってば）
まずは、こんなコードを書いてみます。
try { List<String> strArray = Arrays.asList("abc", "def", "xxx", "ghi", "jkl", "xxx", "pqr", "stu"); strArray.parallelStream().forEach(s -> { System.out.println("ラムダ開始: id=" + Thread.currentThread().getId()); try { Thread.sleep(100L); if (s.equals("xxx")) throw new RuntimeException("ラムダ内で例外: id=" + Thread.currentThread().getId()); } catch (RuntimeException ex) { System.out.println("ラムダ内で例外発生: id=" + Thread.currentThread().getId()); throw ex; } catch (InterruptedException e) { e.printStackTrace(System.out); } System.out.println("ラムダ終了: id=" + Thread.currentThread().getId()); }); } catch (Exception th) { System.out.println("外側で例外をcatch"); th.printStackTrace(System.out); }
要するに、文字列が "xxx" だったら例外を吐く、それ以外は正常終了するラムダ処理です。
これをParallelStreamで実行するものです。
"xxx" は２つあるので、２回例外が発生するようになっていますよね。
さて、これを動かしてみるとこうなります。
ラムダ開始: id=1 ラムダ開始: id=15 ラムダ開始: id=14 ラムダ開始: id=16 ラムダ開始: id=12 ラムダ開始: id=17 ラムダ開始: id=13 ラムダ開始: id=18 ラムダ終了: id=18 ラムダ終了: id=13 ラムダ終了: id=17 ラムダ終了: id=14 ラムダ内で例外発生: id=12 ラムダ内で例外発生: id=1 ラムダ終了: id=16 ラムダ終了: id=15 外側で例外をcatch java.lang.RuntimeException: ラムダ内で例外: id=12
ふむふむ、例外もラムダ呼出しの外側でcatchできました。
…と思ったら、ラムダ呼出しの外側でcatchできたのは、id=12のスレッドのみでした。
id=1のスレッドで発生した例外はどこに行ったのでしょうか？
では、もう一回実行してみましょう。
ラムダ開始: id=1 ラムダ開始: id=14 ラムダ開始: id=15 ラムダ開始: id=13 ラムダ開始: id=16 ラムダ開始: id=17 ラムダ開始: id=12 ラムダ開始: id=18 ラムダ終了: id=16 ラムダ終了: id=15 ラムダ内で例外発生: id=13 ラムダ内で例外発生: id=1 ラムダ終了: id=14 ラムダ終了: id=17 ラムダ終了: id=12 外側で例外をcatch java.lang.RuntimeException: ラムダ内で例外: id=13
ふむふむ...あれ？
今度は、id=18のスレッドで「ラムダ終了」が出ませんでしたよ！
頻度は高くないようですが、ParallelStreamの並列処理には、実はこんな不安定なところがあるようです。
まとめると、
- なぜ、最初の例外しかラムダの外側でcatchできないのか？
- なぜ、終了が出なかったスレッドが存在するのか？
- 終了が出なかったスレッドは、実際には終了したのか、それとも残っているのか？
- ParallelStreamって、Fork-Joinで待ってないの？
そんなところが疑問ですよね。
後編ではその謎に迫ります！
では。
Acroquest Technologyでは、キャリア採用を行っています。
- 日頃勉強している成果を、Hadoop、Storm、NoSQL、HTML5/CSS3/JavaScriptといった最新の技術を使ったプロジェクトで発揮したい。
- 社会貢献性の高いプロジェクトに提案からリリースまで携わりたい。
- 書籍・雑誌等の執筆や対外的な勉強会の開催を通した技術の発信や、社内勉強会での技術情報共有により、技術的に成長したい。
- OSSの開発に携わりたい。
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。
キャリア採用ページ
