Errorを3つに分類する
business ruleとして予期できるエラー
business ruleの一部でありそれへの対処も決まっているのでそれをコードに落とす
domain expertに聞いたら対処法が分かる
型で文書化すべき
e.g. 無効な商品コードを含む注文の対処
Panics
システムを未知の状態にするもの
e.g. ゼロ除算
これについて型ではなく例外を使うと言い切る根拠は何なのだろうmrsekut.icon
panicとは予測できないものなので、型で列挙するのがそもそも不可能だったり、
あるいは列挙したところでhandlingの仕方が同じなので無意味、みたいな感じだろうか？
Haskellでもexception投げるものの存在は使ったことがあったけど、いまいち使い分けに自分の中でロジックがなかったmrsekut.icon
Infrastructure Errors
アーキテクチャの一部として予期されるエラーであるが、どのビジネスプロセスにも含まれず、ドメインにも含まれない
e.g. ロードバランサーへのアクセス接続エラー
型の文書化か、例外かのいずれか良さげな方で対処する
とは言え、型を使う選択肢があるだけでもだいぶマシで、OOPとかの解説書だとあらゆる物をtry..catchで扱うのでかなり雑と言えるmrsekut.icon
Errorようのclassを作ることで文書化するのか
でもそっちのほうが一貫性があるとも言えるか
関連