TypeScript で Railway Oriented Programming 型安全なエラーハンドリングを作る コネヒト・千合同懇親会 @daitasu 

TypeScript の例外処理に Railway Oritented Programming を使おう！ 

Railway Oriented Programming（ROP） ● 2014年にScott Wlaschinさんによって提唱 ● 関数型プログラミングにおける、エラーハンドリングの取り扱いに焦点を当てた 実装手法 ● 関数を「成功」と「失敗」の2つの分岐がある 線路(レール) に見立てる 

Railway Oriented Programming ● 1つの関数が1つ のinput に対し、2つの output パターンを持つ 成功！ 失敗... function input 

Railway Oriented Programming ● 「成功」時は次の処理へ、「失敗」時は何もせず通過する validateLength validateEmail on success bypass 

Railway Oriented Programming ● 各関数の連結 → 成功時のみ値が残り、失敗時は最初のエラー情報が最後 まで届く validateLength validateEmail extractDomain 

Result 型とは ● ROP に則った型定義 ● 言語によって命名が微妙に異なる ● Result 型 ○ Success と Failure の Union 型 ● Result 型を受けてResult型を返す処理も 一緒に必要(Scala だと flatMap 関数) ○ Success　受取り時： 次の関数を実行 ○ Failure 受取り時: 何もせず次へ 

何が嬉しいの？　 

手続き的な例外処理のつらみ Error Handling を 各関数で意識する必要がある (考慮漏れの懸念) TSのtry catch は エラー情報の型を持たない → どのエラーか分からん 

Result 型を適用する 返り値の型を Result 型へ → 型エラーで Handling 漏れに気付ける Success時：値が返却 Error時：エラー箇所の情報を保持 エラー処理の入れ子が減って、 処理が追いやすくなる 

まとめ ● 手続き的エラーハンドリングはしんどい ○ try catch の入れ子の増加と対応漏れの発生 ○ 例外の型が伝播されない ● Result はオススメ ○ ROP によって例外処理の漏れを型安全に防止できる ○ try catch の入れ子を脱せて、煩雑化を防げる ● TS 標準の型ではない ○ TS 標準の型ではなく、オレオレ型定義が生まれる ○ 用法・用量を守って症状を見ながらの使用に留める 

記事 https://daitasu.hatenablog.jp/entry/2025/03/04/090000 TypeScript の例外処理を Railway Oriented Programming(Result 型) で楽にしたい