ようやく、自分の中で例外処理系について頭が整理されてきたので、メモしておく。
実際のシステムは自分一人でやっているわけではないし、色んな制約もあるので、この通りには行かない。あくまで一般論。ま、普通だと思うけど。
例外の区別
①正常処理
・通常の業務処理。業務継続
②業務例外系正常処理
・ビジネスルール違反などの業務例外発生時の処理。
・業務継続。想定可能な例外処理。
③業務例外系異常処理
・滅多に起きないようなビジネスルール違反。想定不可能な場合
・業務停止。運用担当者による違反状態の是正が必要。
④システム例外
・システムの異常、バグ。想定外
・システム停止。運用担当者による是正が必要。
それぞれ、どう対応するかというと。
①正常処理
・普通に
・ログレベルはINFO
②業務例外系正常処理
・原則、言語の例外処理機能を利用しない。
・例外状態は２値管理でいいなら、boolean,３値以上が必要ならEnumまたは専用の 例外オブジェクト（Throwableである必要があるかは悩む。）
・モデリングの本とかでは例外をスローしているけど融通きかないので。
・ログレベルはINFO、もしくは、WARN
③業務例外系異常処理
・業務例外用実行時例外クラスをスローして、止める。
・Java,フレームワークの例外機構を利用してメッセージ出力や画面遷移をする。
・ログレベルは原則ERROR、もしくはWARN？
④システム例外
・システム例外用実行時例外クラスをスローして、止める。
・Java,フレームワークの例外機構を利用してメッセージ出力や画面遷移をする。
・ログレベルは原則ERROR
ということで、ビジネスロジックでTry-catchの構文を書くことはない、というのが原則。そこらへんの例外処理はフレームワークで吸収する。
フレームワークを前提としないなら、Javaの検査例外も活躍しどころがあったと思うけど、例外ハンドラをフレームワークが担うなら、不要ですな。
②と③は流動的で、どれだけ例外状況を想定できて、要件として定義できるか、そして、作りこむほどの価値があるのか、っていう様々な要因で変動すると思う。あと、要件が抽出しきれていないと、②、もしくは最低でも③として整理すべき処理が④になって出てくる。
また、③や④の状況で、非常時モードに設定すると、②として処理することができるようになる、みたいなのもあるのかな。
・システム例外が起きる状況になっても業務を継続したい場合もあると思うが、原則はインフラ側で吸収すべきことと思う。
