エラー、例外の取り扱いの原則

システムは、予期可能なエラーと例外を、期待される挙動になるように、正しく処理しなければならない。

システムは、予期不可能なエラーと例外の場合には、可能な限り安全に処理を中止し、元の状態に戻すか、または状態を保持して、ログを記録し、利用者か管理者に失敗を報告しなければならない。

元に戻すべきか、状態を保持すべきはアプリケーションの仕様に依存する。

中途半端に成功してはならない。どこかで失敗したら、まったくされていない状態に戻っているべき。(Atomic性)

何が成功して、何が失敗したかを残し、失敗したものをやり直せるならば、問題ない。

ログは、原則として、以下の2通りの使い方をされる。

エラー報告。何か悪いことが起きたときに、主に管理者に通知をする。

監査。状況報告。処理が発生したことを記録に残す。後で何がいつ起きたのかを確認できる。

システムは、利用者に対しては、利用者が判断して対処できるメッセージを出力しなければならない。

メッセージの表示領域が十分取れない場合には、代表的なメッセージを出して、それを元にヘルプを参照できるようにする。

利用者として知りたいのは、以下の3つである。

「どういうエラーが起きたのか(事象)」

「なぜそのエラーが起きたのか(原因)」

「どうしたらよいのか(対処)」

利用者として対処できないもの(管理者、開発者、保守者が対処すべきもの)は、利用者に対しては一律「システムエラー」として出力しなければならない。

なぜなら、利用者には管理者に連絡する以外、何もできないからである。

出力するエラーメッセージは「システムエラーです。管理者に連絡してください。」のような物が望ましい。

一時的に失敗している場合は「××に失敗しました。再度お試しください。解決しない場合は管理者に連絡してください。」のような物が望ましい。

メッセージIDとプログラム上のエラー発生場所がわかる物が画面に表示されているのが望ましい。

システムエラーの場合には解析に必要なログやファイルがどこかに残されているのが望ましい。

システムは、ログを、管理者、保守者に分かるように出力しなければならない。

「システムエラー」しか分からないのでは困る。

ユーザーがUI上で出す入力エラーのようなものはいちいちログに残す必要はない。(ただし、ユーザーがなぜ間違えるのかを理解するのにはよい情報である。)

ユーザー(または外部システム)が行ったシステムへの要求は要求ログに残すべきである。

外部システムからの通知などもシステムに影響を与える要求の一種と考えることができる。