作成日 2009/3/29
最終更新日 2009/3/29
[ Japanese | English ]

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

 このページでは例外発生時の処理方針について説明します。

 例外処理はオブジェクト指向設計やオブジェクト指向プログラミングとは関係なく行います。そのため、このコンテンツ内にはふさわしい内容ではないと思い長い間書きませんでした。
 しかし、例外処理は、正常処理よりも設計量・プログラミング量が多いことがあるし、重要な概念であるため、説明することにしました。

 
1.例外とは
2.例外が発生したときの設計方針
3.参考文献など


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

このページのトップへ

3.参考文献など

 このページを作成するのに参考にしたページ、及び、書籍です。

番号

リンク先の名称

リンク先の説明

リンクした日

1 例外処理 - Wikipedia  例外処理についての説明があります 2009/3/29 
2 エラー処理とログ出力 例外が発生したときの処理方法について書かれています 2009/3/29
3 エラー処理設計:対処方法をシステム全体で定める 例外が発生時の処理の設計について書かれています 2009/3/29

番号

著者名

書籍名

ISBN

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


Prev Up Next  Top
このページのトップへ

このページの利用によって発生した、いかなる損害について、このホームページの作成者は責任を負いません。
このページの間違いや嘘を見つけた方、このページに書いて欲しい情報がある方はメールをお願いします。

Microsoft 、Windows 、Visual Basic および Excel は米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。
ここではExcel® をエクセル、Visual Basic® for Applications をVBAと表記する場合があります。
Mac 、Mac OS 、Mac OS X は米国Apple Computer,Inc.の登録商標または商標です。
Java及びすべてのJava関連の商標及びロゴは、米国及びその他の国における米国Sun Microsystems,Inc.の商標または登録商標です。
その他、社名および商品名、システム名称などは、一般に各社の商標または登録商標です。

このホームページの作成者はこれらの会社とはいっさい関係がありません。