いまいち使い方がいい加減だった例外処理について、復習がてらメモします。
昔のリンクを整理して出てきた例外リンクはこちら(Javaですが今のPHPにも当てはまるかと思います。)
Contents
例外は例外の時に
読んで字のごとくですが、通常では起こりえない時に「例外」を発生させます。
典型的なのは以下のようなケースですね。
- メモリのオーバーフロー
- DB接続失敗
- アクセス制御失敗
- ファイルなどが不存在
通常、プログラマが制御可能なもの( Exception )と制御不可能なもの( Error )に分かれます。
Error とは StackOverflow のようにプログラマが直接制御するのが極めて難しいものになります。基本的には Exception の部分に記述して行くことになるかと思います。
RuntimeException
Exceptionの中でも、Fileがない(FileNotFoundException)、クラスがない(ClassNotFoundException)などは必須の処理になりますが、それ以外の任意で追加するエラーのものは RuntimeException となります。
なお、細かいクラス分けは例外処理について その２を参考に。
上記のようなケースはわかりやすいのですが、ビジネスロジック上でも通常では起こりえないケースにて記します。
- ユーザー情報を定義するメソッドでユーザーが存在しない
- 通常処理であれば在庫があるはずなのに在庫がマイナスになってしまっている
- 絶対必要なはずの引数が存在していない
・・・
(上記のようなケースは設計やプログラムがしっかりしていれば防げるため、書くべきでないというかたもいるようです。)
以下ではそのようなエラーを書く時に気をつけるべきことを明記していきたいと思っております。
エラークラスを細かく分ける
全てthrow RuntimeExceptionなどとするのではなく、RuntimeExceptionを継承して、個別にクラスを分けましょう。
通常のコードを書く時と同じですが、分類し、細かく分けることが必要になってきます。
そのためにいきなりコードを書くのではなく、どういったエラーがあるかをまず分類する、メモとして残す必要が出てきます。
try{}catchを適切な長さにする
通常のコードを描くときと同じですが、スコープが長すぎると原因の追及などが追えなくなったりします。またtry{}catchでcatch時にrollback、(正常系の最後に)commitなどと書くケースが多いですが、これまたスコープが長すぎると、非常に不便になります。
通知処理(画面)
画面に出す情報はユーザーにわかりやすくしましょう。詳細なエラーメッセージ(スタックトレースなどを)画面に出してもユーザーにはわかりません。
障害報告などがあった時に原因を検知しやすくするため、何がまずいのかを記しましょう。「システムエラーです」では何が悪いかわかりません。コードがあれば別ですが・・・・
通知処理(告知)
障害があった時にいち早く気づけるように通知ライブラリを使うなどしましょう。
エラーコード
上記のユーザー側に出すエラーですが、できればエラーを分類し、コード化しておきましょう。
そうすることでどんなエラーがあり、どう対処すればいいかがわかります。
開発と本番で表記を分ける
画面に出す情報を開発と本番で分けるようにしましょう、例として詳細なスタックトレースを開発時には画面に出しておき、本番では伏せ、エラーコードだけにするなどです。
参考になったリンク
複雑さに潜り込む – 大規模PHPアプリケーションにおける例外・モニタリング・ロギング
このネタはまた書くかもです・・
