これはなに
例外っていつ使うの？ とおもったので調べる
整理
【PHP】実践的な例外処理の設計について
- いつ例外を使うべきか？
- ふつう起きない処理を捉えるためには例外
- 異常な状態であり、プログラムの実行を止めても良い状態
- システムエラー
- ふつうに起きうるなら要件に組み込む
- ユーザーに再入力を求めれば良い場合などは例外ではない
- 業務エラー
- 例外への対処
- メッセージを開発者に投げ、問題に対処させる
例外設計における大罪
- よっつの大罪がある
- 無視
- 隠蔽
- 乱用
- 過剰防御
- 無視
- でているエラーを放置する
- 隠蔽
- キャッチして握り潰す
- 乱用
- try catchでループを抜ける、みたいな例外以外での利用
- 過剰防御
- その処理がよばれるための事前条件は外部の処理に任せて良い。あえて内部で例外処理しようとしなくて良い
- 責務の話
例外処理とロギングのベストプラクティス
- 業務エラーに例外を使うな
- UI処理が絡むやつをかくな、なぜならキャッチに業務処理を書いてはならないから
- 例外は処理コストが高いので、正常処理に組み込むべきではない。
- 常に走る処理で毎回例外処理させるなってことかな
- 入力エラーは複数の原因がある、例外は基本ひとつ返すだけなので相性悪い
- 無理にやろうとすると例外が複雑になる
- すべきなのは外部システム連携におけるエラーとか
- 開発者が対応しないといけないやつ
- try catchは基底クラスにまとめる
- コントローラーから呼び出されるやつら
- MVCのモデルにあたる、と記載あるけどどうなんだろう
- レイヤードアーキテクチャとか、アーキテクチャ構造によっては書くべき層が異なりそう
- ロギング
- try, catch, finalyのそれぞれにログを出す
- 開始、例外、終了のメッセージ
- ロギングで表現すべきこと
- 時刻
- スレッド番号
- ユーザーID
- ログレベル
- メッセージコード
- 任意メッセージ
- スタックトレース
- ログは処理重たいので書く量も考えること
感想
- 例外って、なんか、発生する条件と例外クラスが分離してて、間違って使いそうで怖いなと思う