Exceptionハンドリングの基本と新しい手法について【JJUG CCC 2023 fall】

Copyright (C) 2023 Toranoana Lab Inc. All Rights Reserved. #jjug_ccc_abc
例外処理の基本と新しい手法について虎の穴ラボ　河野裕隆 JJUG CCC 2023 Fall T O R A N O A N A L a b

好きなもの • VOCALOID（初音ミク） • 謎解き、クイズ今期おすすめアニメ • SHY • 葬送のフリーレン自己紹介河野裕隆 • 2019/08 虎の穴ラボ入社 • 新規開発チーム ◦ クリエイティア他虎の穴ラボへの入社理由 • スキルを高めあえる仲間がほしい • ユーザーに近い仕事がしたい JJUG CCC登壇は1年ぶり2回目 2

• Exceptionの基本 ◦ チェック例外 ◦ 非チェック例外 • ハンドリング手法 ◦ try-catch ◦ Throw • 他言語の対応 • パターンマッチングによるハンドリング話すこと 3

• Step Upセッション ◦ 初学者～を対象としています • 例外について再整理したい人対象者 4

そもそもException（例外）って？ 5

辞書的な意味：通例の原則にあてはまっていないこと一般的な話 6 プログラミングの文脈実行の継続を妨げる異常な事象（例） • あるはずのファイルがない • データベースにアクセスできない

例外の役割 7 • 大域脱出 ◦ 処理を中断して、ハンドリングしてくれる呼び出し元まで戻す • 通常（正常時）の戻り値とは違う型の返却 ◦ 呼び出し元に正常時とは違うことをしてもらうときに「例外の型」で判断してもらう

• 実行時にErrorとExceptionを発生させて処理する ◦ Error：プログラム上では対処不可のもの ◦ Exception：プログラム上で処理できる可能性があるもの（補足）コンパイルエラーコンパイル時（実行前）に文法エラー等を検知 Javaでの話 8

• 実行時にErrorとExceptionを発生させて処理する ◦ Error：プログラム上では対処不可のもの ◦ Exception：プログラム上で処理できる可能性があるもの Javaでの話 9

クラスの関係図 Throwableを継承 Exceptionは RuntimeExceptionとその他の例外にわかれる ErrorとExceptionとRuntimeException 10

チェック例外 RuntimeExceptionを継承していない発生可能性と処理を明示する必要性非チェック例外 RuntimeExceptionを継承している処理を明示する必要がない ErrorとExceptionとRuntimeException 11

チェック例外 IOException、SQLExceptionなど主にファイルの有無や外部との疎通非チェック例外 NullPointerException、 IllegalArgumentExceptionなど実装時の考慮漏れやあえて例外に倒している箇所チェック例外/非チェック例外のサンプル 12

Exceptionが起きたらどうすればよいか 13

例外をそのまま呼び出し元に伝播させる Throw 14 try-catch 例外の伝播を止めて、処理をする

Throws // ユーザーサービスの実装 public User findByName(String name) throws UserNotFoundException{ return users.stream().filter((u) -> u.name().equals(name)).findFirst().orElseThrow(UserNotFoundException::ne w); } メソッドの定義のあとに「 throws 発生するクラス名」で上位に例外発生可能性を知らせることができる 15

throw new UserNotFoundException();// 呼び出し元に例外を渡す try { // 例外が起こる可能性がある処理 } catch (SampleException e) { // ハンドリングする例外 throw new UserNotFoundException(e); // 例外のラッピング } try { // 例外が起こる可能性がある処理 } catch (SampleException e) { // ハンドリングする例外 throw e; // 例外の再Throw } Throw 16

UserService userService = new UserService(); String searchUserName = "test"; Optional<User> user = userService.findByName(searchUserName); if(user.isEmpty()){ throw new UserNotFoundException(); } // ユーザーサービスの実装 public Optional<User> findByName(String name) { return users.stream().filter((u) -> u.name().equals(name)).findFirst(); } Throw 17

try { // 例外が起こる可能性がある処理 } catch (SampleException e) { // ハンドリングする例外 // SampleExceptionの例外が起きた場合の処理 } catch (Exception e) { // ハンドリングする例外 // その他の例外が起きた場合の処理 } finally { // 例外が起きても起きなくてもやって欲しい処理 } try-catch 文法 18

UserService userService = new UserService(); String searchUserName = "test"; try { userService.findByName(searchUserName); } catch (UserNotFoundException e) { System.out.println("ユーザーが見つかりませんでした。 (" + searchUserName + ")"); } // ユーザーサービスの実装 public User findByName(String name) throws UserNotFoundException{ return users.stream().filter((u) -> u.name().equals(name)).findFirst().orElseThrow(UserNotFoundException::ne w); } try-catch 実装例 19

throwsを書く 1. チェック例外をthrowする場合 2. チェック例外がthrows句にあるメソッド呼びcatchしない場合 =>書かないとコンパイルエラー catchしてハンドリングする 1. チェック例外がthrows句にあるメソッド呼び、catch伝播を止める場合 a. RuntimeExceptionでラップしてthrowする b. 適切に処理して正常系に戻すチェック例外でやらないといけないこと（非チェック例外でも可能） 20

- 適切に処理して正常系に戻す - その例外を開発者に通知する必要があるかを考える - 正常系に戻してしまうと問題の発覚が遅れる原因に - ログを出した上で正常に戻す等が必要 catchしてハンドリングする上で注意が必要なこと 21

他言語ではどうしているのか 22

多値返却でカバー 1. 複数の値を戻り値にできる 2. panic/defer/recoverでtry-catchに近い動き a. panic：throwのような動き b. defer：ﬁnallyのような動き c. recover：catchのような動き（大域脱出は基本的にない） =>Javaの例外が乱用された結果の言語思想 Go 23

回復可能なケース：Result<T, E> =>パターンマッチでT型とE型で処理を分岐してハンドリング回復不可なケース：panic!（Javaで言うexitに近い） =>プログラムの強制終了に近いため、大域脱出とは異なる Rust 24

すべてが非チェック例外 begin-rescueでtry-catchと同等の処理 raiseでthrowと同等の処理 Ruby 25

パターンマッチングによるハンドリング 26

Java21（LTS 2023/9～） switchで • 型によるパターンマッチが使えるように • シールクラスによる網羅担保ができるように =>catchの中で柔軟なハンドリングが可能に？パターンマッチ 27

UserService userService = new UserService(); try { userService.createUser("test", 25); userService.findByName("test"); return renderUserDetail(); } catch (UserExceptionBase e) { return switch (e) { case UserNotFoundException ex -> renderNotFound(); case UserNotUniqueException ex -> renderParamError(); } } パターンマッチによる分岐 28

Java17（LTS 2021/9～）クラス/インターフェイスの継承先を制限 =>親クラスに対する子クラスが自明になるシールクラス 29

// sealed で宣言し、permits で継承先を制限 public abstract sealed class UserExceptionBase extends Exception permits UserNotFoundException, UserNotUniqueException {} // UserExceptionBaseを継承、finalで子クラスを制限 public final class UserNotFoundException extends UserExceptionBase{} // UserExceptionBaseを継承、finalで子クラスを制限 public final class UserNotUniqueException extends UserExceptionBase{} シールクラスの例外処理への応用 30

UserService userService = new UserService(); try { userService.createUser("test", 25); userService.findByName("test"); return renderUserDetail(); } catch (UserExceptionBase e) { return switch (e) { case UserNotFoundException ex -> renderNotFound(); case UserNotUniqueException ex -> renderParamError(); } } パターンマッチによる分岐 31

• catchを繰り返すより可読性が高い • 例外が追加になった際に実装漏れが起きない • ドメインごとにパッケージが切られていれば、わりと共通的にハンドリングできるメリット 32

• 結局複雑度はそこまで変わらない • ドメインごとに例外クラスを作る必要があり、クラス数が膨大になる ◦ ドメインでわけないの不要な分岐をいたるところにたくさん書くことになるデメリット 33

例外対応への考え方 34

• 例外は例外である（当たり前ですが） • 今回のコードでは不必要に例外を使っている ◦ 処理結果用オブジェクトでハンドリングしたほうが良い場合が多い • NullPointerException等もcatchするのではなく事前のチェック（validation）で対処したほうが良い改めて例外とはなにか 35

SIerで作業していたころ • コーディングが縦割りだったため、他のメンバーに意識してもらうために例外としておく例外への考え方の変化 36

現在（自社サービス） • 極力発生させない、例外ではなくメッセージの伝播で対応する ◦ 例外を例外時しか発生させないことで見通しをあげるコンウェイの法則組織構造がアーキテクチャに影響を与える例外への考え方の変化 37

• 例外処理は必須 • パターンマッチ/シールクラスの恩恵は例外処理でも受けられる ◦ 例外を大量に扱うのはキツイ・・・ • 例外処理は少ないに越したことはないまとめ 38

Exceptionハンドリングの基本と新しい手法について【JJUG CCC 2023 fall】

Exceptionハンドリングの基本と新しい手法について【JJUG CCC 2023 fall】

More Decks by 虎の穴ラボ株式会社

Other Decks in Technology

Featured

Transcript