例外が発生したときの処理方針

1.例外とは

1. ユーザの入力ミスを検知した
2. 開きたかったファイルが無かった
3. ファイルの読み込みや書き込みに失敗した
4. nullポインタに対してアクセスしようとした
5. 数値を0で割ろうとした
6. 割り当てられている配列の最後の要素を超える要素にアクセスしようとした
7. ネットワークにアクセスできなかった
8. DB(Database)にアクセスできなくなった
9. SQLで失敗した
10. ヒープメモリが無くなった

2.例外が発生したときの設計方針

1. 取得していたリソース（メモリ、ミューテックス、スレッドなど）を解放する。
   　具体的に言うと、確保していたヒープメモリは解放し、DBコネクションは切断し、開いているファイルは閉じます。その他、ミューテックスはロック解除し、スレッドは停止させます（他にもある）。
   　解放してあげないと、さらに状況が悪くなったり、他に動いているプログラムに迷惑がかかる可能性があります。
   
   
2. 例外が発生したことをユーザに知らせる。
   　例外が発生した⇒処理に失敗したです。ちゃんと知らせないとまずいです。
   　ただ、問題なのは何の情報をどこまで詳しく出すかです。
   よく言われるのは「ユーザが何をすればよいか」が分かることです。
   まあ、「システム管理者に問い合わせてください」となるのが多いのですが…。
   
   
3. 例外が発生したことを記録（ログ）に残す。
   　これがないと、後で解析が出来ません。解析が出来ないと対策がとれません。
   　「記録に残す情報」は発生日時、原因はもちろん出力した方が良いと思います。
   　Javaのjava.lang.Throwable.printStackTrace()メソッドのようにトレース（クラス名、ソースのファイル名、メソッド名、行数）があると良いのですが、言語がサポートしていない場合は難しいです。
   
   
4. データを破壊したり、消したりしない。いざと言うときにバックアップを保存しておく。
   　データが残っていれば、最悪復旧できます。
   　不正なデータを書き込んでしまった場合や消した場合はバックアップからデータを戻すことになりますが、当然、データをバックアップしていなければ無理です。仮にバックアップから戻せたとしても、「何日前のデータなんだよ」ということも考える必要があります。
   
   
5. メールする。
   　自動でシステム管理者の携帯電話にメールするようにする場合もあります。
   　マジで勘弁して欲しいです…。

　そうそう、この場合は結構、ちゃんとした設計が必要になります。
　なぜかと言うと、システムの制約（ディスク容量、ネットワーク）の影響が考える必要があるのと、どこまで必要かはシステムによるからです。また、やろうとすればするほどコストもかかるのでどっかで折り合いをつける必要が出てきます。また、例外に対する処理で例外が発生するときもあるので意外と厄介です。




　最後に2点ほど。
１．アンチパターンの書籍をみると、例外処理においてやってはいけないことが書かれている（The Man with the Axeアンチパターン、Ignoring Realityアンチパターン）ので是非とも読んでみてください。
２．例外は発生するものとして設計しましょう。「起こらないだろう」は大変危険です。繰り返しになりますが、正常処理よりも例外処理の方が設計もプログラミングも時間がかかることがあります。例外発生時の処理がうまくできない場合もあると思いますが、そのときはシステムの制限事項としましょう。

3.参考文献など

番号	著者名	書籍名	ISBN
1	Bill Dudney / Stephen Asbury / Joseph Krozak / Kevin Wittkopf 著,  トップスタジオ 訳	J2EEアンチパターン	978-4822281984