エラー処理について - blog.beaglesoft.net

先週までは小説をひたすら読んだわけですが、そろそろ技術書が読みたくなってきました。いろいろと読みたいものは多いのですが、毎年読んでいる書籍を読み返すことから始めようかと思います。

毎年飽きもせず同じ書籍を読み返すのですが、そのうちの一冊（正確には二冊）が Code Complete第2版〈上〉―完全なプログラミングを目指してとCode Complete第2版〈下〉―完全なプログラミングを目指してです。数年前の書籍ですが、内容は王道をいっているのではないかと思います。

早速読み返しているわけですが、忘れていることや気づかなかったことが多くありとてもよい勉強になります。基本的にはソフトウェアコンストラクションをいかに行うかを解説している書籍なのですが、その説明がとてもわかりやすく体系立って勉強したことのない私には教科書的な書籍です。

そんなコードコンプリートの中で、以前から対応に苦慮してきたエラー処理について記述があったのでまとめておこうと思います。エラー処理や業務処理については、.NETエンタープライズWebアプリケーション開発技術大全〈Vol.5〉トランザクション設計編 (マイクロソフトコンサルティングサービステクニカルリファレンスシリーズ―Microsoft.net)にも詳細はありますが、もう少し大局的にとらえた内容です。

エラー処理では、エラーを修正するのか検出するだけなのかを検討する。エラーを修正する場合、プログラムはエラーからの回復を試み、エラーを検出するだけの場合は、プログラムは何もなかったかのように処理を続けるか、処理を中止する。 →業務内容によりケースバイケース。集約的に例外を補足する場合には基本的には処理を中断するかな。
エラー検出は能動的に行うのか受動的に行うのかを検討する。 →基本的には能動的にエラー検出を行うなぁ。特にUIのあるシステムでは入力チェックは必須。
プログラムがエラーをどのように伝達するのか検討する。
エラーメッセージを処理するためのメッセージ規約はどのようなものかを検討する。エラーメッセージ規約が定まっていない場合、ユーザーインターフェースがプログラムのあちこちで食い違いシステムの一貫性を欠いてしまう。
例外はどのように処理するのかを検討する。アーキテクチャには、コードがどのような状況で例外をスローするのか、それらの例外がどこでキャッチされるのか、ログにどのように記録されるのか、どのように文書化するのか。
プログラムのどのレベルでエラーを処理するのか検討する。 →基本的には例外はハンドルしないで集約的に処理を行う。
各クラスは入力データをどの程度検証するのかを検討する。 →システムの境界は例外を、システム内部はAssersionを利用するかなぁ。
実行環境に組み込まれている例外処理メカニズムを使用するのか、それともそのようなメカニズムを独自に構築するのか検討する。 →組み込まれているものを利用するのが基本的なスタンス。

最近経験したことですが、どこまでがシステムとして正常かどうかについての判断は各人結構異なっているものです。システムが動作しなくなるようなことが発生しないような予防的措置を検討した場合に、どこまでを現実的なラインとするかは明確にしなければシステムの安全性に関わってきます。

エラー処理について検討すると常に「運用で対応…」という話になるのですが、どのように運用で対応するかを検討してこそ初めて対応が可能となるわけです。そのことから考えても、上記のエラー処理をどのように設計するかはきわめて重要なのではないかと感じています。

ということで、自分が設計するときのエラー処理メモでした。