エラー処理の選択肢を増やす ~try-catchから始めて段階的に型安全へ~
1.6K Views
November 14, 25
スライド概要
ソフトウェアエンジニア at @codmon_official Kotlinをよく書いてます。Goも好きです。
関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1.1M
各ページのテキスト
エラー処理の選択肢を増やす ~try-catchから始めて段階的に型安全へ~ JJUG CCC 2025 Fall 上代 洋平
自己紹介 上代 洋平 かじろ ようへい サーバーサイドの開発でKotlinを使ってます！ 2022.12 コドモンに入社 現在 エンジニアリングマネージャー 2
今日持ち帰ってほしいこと ● エラー処理の選択肢を知る ● 使い分けの判断基準を持つ 3
前提 ● このセッションでは Kotlinをベースに説明します ○ コード例は主にKotlin ○ arrow-ktライブラリを使用 ○ 考え方はJavaにも適用可能 4
エラー処理、こんな感じになってませんか？ 5
何が問題なのか？ ● エラーの種類を区別できない ○ User? だけでは「なぜ失敗したか」が分からない ○ NotFoundとDBエラーを区別して処理できない 6
「値で返す」という選択肢
Either/Result ● エラーを「値」として返す ● 成功 or 失敗 を型で表現する 8
Eitherとは 9
Either 10
Eitherのメリット ● エラーの種類が型で表現される ● 処理漏れがコンパイルエラーになる ● エラーが値として扱える 11
エラーの種類が型で表現される 12
処理漏れがコンパイルエラーになる 13
エラーが値として扱える 14
すべてをEitherにする必要はない
全てをEitherにすると…？ ● 型の複雑化 ○ 失敗しない処理にまでEitherを使う ● 無駄なエラーハンドリング ○ 丁寧に処理する必要がないエラーまでEitherにする ○ コードが複雑になるだけであまり意味がない 16
全てをEitherにすると…？ 17
全てをEitherにすると…？ 18
上手く共存させる
上手く共存させる ● EitherもExceptionも使う ● 適材適所で使い分けることが大事 20
どう使い分ける？
EitherとException の使い分け ● Either ○ 予期できるドメインエラー ○ バリデーション失敗、ビジネスルール違反 ○ 正常系の一部として設計に含める ● Exception ○ 予期しないシステムエラー ○ DB接続エラー、ネットワーク障害 22
これだけだと判断が難しい
レイヤードアーキテクチャだと考えやすい
EitherとException の使い分け 25
EitherとException の使い分け ● Domain Layer： Either（ビジネスエラー） ● Infrastructure Layer： Exception（システムエラー） ● Application Layer： Eitherの組み合わせ ● Presentation Layer： Either → HTTPレスポンス 26
Domain Layer ● Either でビジネスルールを検証 ○ バリデーション ○ ビジネスロジック 27
Domain Layer 28
Infrastructure Layer ● Exception をそのまま投げる ○ データベースアクセス ○ 外部APIコール 29
Infrastructure Layer 30
Application Layer ● Either のみ処理 31
Application Layer 32
Presentation Layer ● 両方を適切に変換 ○ Either → HTTPレスポンス ○ Exception → ExceptionHandler 33
Presentation Layer 34
まとめ
持ち帰ってほしいこと ● エラー処理の選択肢を知る ○ Exception ○ Either ● 使い分けの判断基準を持つ ○ 予期できるドメインエラー → Either ○ 予期しないシステムエラー → Exception ○ レイヤーごとの役割を意識する 36
ご清聴ありがとうございました