Modern Typed error handling in Kotlin ~Context Parametersを介したエラータイプの受け渡し~

Kolin Conf 2024で紹介されていたKolinの新しいエラーハンドリングについてのセッションを少し深堀りしてまとめた内容です

Transcript

1. Modern Typed error handling in Kotlin Context Parametersを介したエラータイプの受け渡し のまど (novumd)
2. のまど (novumd) 新卒2年目のAndroider 関数型プログラミングのパラダイムに強い関心を持っていて、 ソフトウェアを安全に動かすための仕組みを学ぶことがモチベーション 一番好きで影響を受けた言語は、Rust 最近の趣味 q Elixirの英語教材を進めy q nowinandroid探{ q バイクツーリングで東京いこかな novum-d @DroidParrot
3. Agenda Ç 回復可能なエラーと回復不能なエラー 7 Exceptionで回復不能なエラー Y Context Parameters と Raise DSLで回復可能なエラー s エラータイプのレイヤリング
4. ÁÈ 回復可能なエラーと回復不能なエラー
5. そもそも、エラーとは？ 回復可能なエラーと回復不能なエラー エラーという言葉の捉え方
6. エラーは、不具合を伝達する仕組み 回復可能なエラーと回復不能なエラー エラーという言葉の捉え方 ↓ 例えば、普段コードを書いていると ... コンパイラは、プログラマにコンパイルが通るまでに「何かしら対応を行うことを要求」してくる この要求により、プログラム実行前に「適切に対処しているか」を確認することで コードの誤りを発見し、プロダクトとして扱えるまでソフトウェアを頑健なものにできる
7. ≒ 回復可能なエラーと回復不能なエラー エラーという言葉の捉え方 人間が感じる痛み ソフトウェアのエラー 不具合を伝達する仕組み
8. 回復可能なエラーと回復不能なエラー エラーという言葉の捉え方 不具合を伝達する仕組みである「エラー」により、原因を特定して ソフトウェアを修復する その原因を大きく「回復可能なエラー」と「回復不能なエラー」の ２つに分けることで安全なエラーハンドリングを実現でき、 将来的にメンテナーが原因特定にかけるコストを下げることができる
9. 回復可能なエラー 回復不能なエラー ユーザーに対して通知するエラー プログラマに対して通知するエラー T ソフトウェアは継続して実行されx T 問題をユーザーに報告し、処理の再試行を促a T プログラムを完全にストップさせるほど深刻ではない T ソフトウェアは異常終了すx T 問題をプログラマに報告し、コードの修正を促a T 不正なデータアクセスによりコードを脆弱性に晒す可能性がある 回復可能なエラーと回復不能なエラー ソフトウェアにおけるエラーは大きく2️つにわけられる 例）ファイルを開こうとして、 ファイルが存在しないために処理が失敗した 例）配列の境界を超えた箇所にアクセスしようとして処理が失敗した
10. 続いて、この２つのエラーの使い分けについて 回復可能なエラーと回復不能なエラー Next
11. ２. Exceptionで回復不能なエラー
12. Exceptionで回復不能なエラー 例外を回復不能なエラーとして扱う 回復不能なエラー プログラムが処理できない状態であり、不正な値で処理を継続する のではなく、 プロセスに処理を中止するよう通知する BOOM！ アプリケーションのクラッシュ Kotlinは、非検査例外なので try-catchで囲む必要はない
13. Exceptionで回復不能なエラー 回復不能なエラーのユースケース x‡ Examples、プロトタイプコード、テスq R‡ プログラマがコンパイラよりも多くの情報をもっている場D a‡ 不正な値でユーザーを危険にさらす可能性がある場合 ”“ –“ あと NaN マイルで undifined 会員 s“
14. Exceptionで回復不能なエラー 回復不能なエラーのユースケース 10 7P Examples、プロトタイプコード、テスト 安全なコードに置き換える前のマーカー (プレースホルダー) として、コード内に例外を残す
15. Exceptionで回復不能なエラー 回復不能なエラーのユースケース 4T プログラマがコンパイラよりも多くの情報をもっている場合 ハードコーディングされた値を「常に有効な値である」と 判断できるほどコンパイラは賢くないため、 プログラマが明示的にアンラップしてあげる必要がある 将来的にユーザーからの入力などで値が動的になる可能性を考慮し、 「ハードコードが有効な値であること」を伝えるメッセージを残しておくと、 のちに作業者が行うエラーハンドリングへの移行が容易となる ¬«
16. Exceptionで回復不能なエラー 回復不能なエラーのユースケース IQ 不正な値でユーザーを危険にさらす可能性がある場合 あと NaN マイルで undifined 会員 sr 誰かが自分のコードを呼び出して不正な値を渡してきたら、 場合によっては、例外を投げて開発段階で修正できるように コードにバグがあることを関数の使用者に通知する 不正な値が利用され続けた結果で起きる インシデントはなんとしても避けなければならない
17. !" Context Parameters と Raise DSLで 回復可能なエラー
18. Context Parameters と Raise DSLで回復可能なエラー 発生した例外を安全なエラータイプとして扱う 回復可能なエラー プログラムを完全にストップさせるほど深刻ではない状態であり、 発生した例外を解釈して、 アプリケーション画面などの インターフェースを通じてユーザーに問題を通知する アプリケーション内でのエラー表示 通常、Happy path(いわゆる正常系のこと)を 通ることを想定するが、例外が発生した場合 は安全なエラータイプ(Raise<E>)として扱う
19. Context Parameters と Raise DSL Context Parameters 関数で使用されるコンテキストをパラメータとして、 シグネチャから分離することができるKotlinの機能 (KEEP) 「block: T.() -> R」のような関数におけるコンテキスト「T」が、呼び出し先の関数スコープへ受け渡される ~ Note ~ Context Receiverの後継であるContext Parametersは、 まだ使用できないため実験的な機能として使えるContext Receiver を例として記述しています 関数のロジックや責務において依存はするものの必ずしもロジックの 本筋には関係ないような依存性について分離することができるため、 関数シグネチャから読み解く関数の仕様が分かりやすくなる Context Parameters と Raise DSLで回復可能なエラー
20. Raise DSL Kotlinの新しいTyped error handling Raiseでは、関数の戻り値として「Happy path と Unhappy pathの両方に対応するためのラッパー型」を提供するEither とは異なり、関数の戻り値には「Happy path の型のみ」を指定する Context Parameters と Raise DSL Context Parameters と Raise DSLで回復可能なエラー New !
21. ROP (Railway Oriented Programming) ROP (Railway Oriented Programming) 2014年にScott Wlaschinによって提唱された関数型プログラミングを行う中で 「エラーハンドリングをどう扱っていくか」に焦点を当てたプログラミング手法 ROPでは、エラーハンドリングを鉄道 (Railway)の車線に例える 関数の入力 (Input)に対して、「Happy path (正常系- Success) 」と「Unhappy path (異常系 - Failure)」の２つの異なる出力を得られる このような分岐を生じる関数を「Switch function (スイッチ関数)」と呼ぶ Input Failure Success Context Parameters と Raise DSLで回復可能なエラー
22. ROP (Railway Oriented Programming) Context Parameters と Raise DSLで回復可能なエラー なお、一度 Unhappy path に入ってしまうと、 基本的に「Happy pathに は決して戻さない」 スイッチ関数はコールスタックを積むことで、 2路線の鉄道を延長できる という点に注意！
23. 最後に、Layered Architectureでの エラータイプのレイヤリングについて エラータイプのレイヤリング Next
24. Æ エラータイプのレイヤリング
25. エラータイプのレイヤリング Layered Architectureにおけるエラータイプのレイヤリング P Use-casV P Domain ServicV P Validation ... etc P Ui State P Repositorh P Networf P Database ... etc raise raise UI Layer Domain Layer Data Layer Context Parametersを介したRaise DSL`context(Raise<E>)` により、 エラータイプを上位層に伝え、最後は Ui State に変換する
26. エラータイプのレイヤリング Layered Architectureにおけるエラータイプのレイヤリング Domain Layer(Usecase) Data Layer(Repository) raise ROPでイメージすると...こんなかんじ ↑
27. エラータイプのレイヤリング Githubリポジトリ検索のユースケースのエラータイプレイヤリングの例 Domain Layer Data Layer Raise<E>に指定するエラー型は、 「各階層のエラータイプを一つにまとめる共用体型(Unit type)」 で定義する
28. エラータイプのレイヤリング Githubリポジトリ検索のユースケースのエラータイプレイヤリングの例 Domain Layer Data Layer 共用体型(Unit type)で定義することにより、 UseCaseのエラータイプとして、 下位のData Layerのエラータイプも含めることができる
29. (おまけ) 回復不能なエラーから回復可能なエラーに置き換える エラータイプのレイヤリング Data Layerで扱うライブラリが投げる例外は、 呼び出し時に安全な型に変換しておく 例外を投げる可能のある関数は、呼び出し時に安全 な型に変換してくれる関数を作っておくと便利 !
30. まとめ 回復可能なエラーと回復不能なエラーを意識して使い分けると、 安全(Type-safe)なエラーハンドリングが自然とできるようになる これからKotlinでTyped error handlingするときは、ROPをイメージしながら Context ParametersとRaise DSLを使ってみるといいかも! エラーは、ソフトウェアにおける「不具合を伝達するため仕組み」であり、 メンテナンスコストを下げるために初めに問題の切り分けを行っておくといい
31. 参考 t Kotlin Conf2024 - Unlocking the Power of Arrow 2.0: A Comprehensive GuidU t Kotlin KEEP - Context Parameterd t F# for Fun and Profit - Railway Oriented Programminh t ArrowKt - Working with typed errord t Scala 3 Reference - Using Clauses