エラー処理とログ出力

エラーを知らせる仕組み

ソフトウェアが走っていると、ユーザが入力した値が適切でなかったり、ファイルが開けない等の、さまざまなエラーが発生します。時には、ソフトウェアにバグがあって、予期しない値が現れることもあるかもしれません。

関数やクラスといったソフトウェア部品を作る際は、その中でエラーが起きた時に、エラーが発生したことを呼び出し側に知らせる処理を、きちんと組み込まなくてはいけません。

C言語による開発では、関数でエラーが発生した時は、エラーコードという数値を返す、という方法が一般的に使われてきました。

C++言語やJava言語といったオブジェクト指向言語では、例外という仕組みが備わっています。処理中にエラーが発生した場合は、例外を投げて、処理を途中で抜けることができます。しかし、C言語の延長でC++言語を使っている場合は、C++言語でもエラーコードを使うことも多くあります。

エラーコードはいくつにする？

ソフトウェアの開発を始めるにあたって、エラーコードをどうやって決めるかは、しばしば悩むところです。

#define XXX_OK                  0
#define XXX_FILE_NOT_FOUND      1001
#define XXX_FILE_READ_ERROR     1002
#define XXX_ILLEGAL_NAME        2001
#define XXX_ILLEGAL_USER        2002
            

class Foo {
public:
        enum ReturnCode {
                OK,
                FILE_NOT_FOUND,
                ILLEGAL_NAME
        };

public:
        enum ReturnCode bar ( ) {
                        :
                return ILLEGAL_NAME;
                        :
                return OK;
        }
};
            

Foo foo;
enum Foo::ReturnCode ret = foo.bar();
if (ret == Foo::ILLEGAL_NAME) {
        // エラー処理
}
            

class ErrorCode {
};

ErrorCode* XXX_OK = new ErrorCode;
ErrorCode* XXX_FILE_NOT_FOUND = new ErrorCode;
ErrorCode* XXX_FILE_READ_ERROR = new ErrorCode;
ErrorCode* XXX_ILLEGAL_NAME = new ErrorCode;
ErrorCode* XXX_ILLEGAL_USER = new ErrorCode;
            

const ErrorCode* ret = foo();
if (ret == XXX_ILLEGAL_NAME) {
        // エラー処理
}
            

エラーの伝言ゲーム

関数が別の関数を呼び出し、そこからさらに別の関数を呼び出す、という具合に、関数の呼び出しが連鎖することは良くあります。

ここで、下位の関数でエラーが発生した時、上位の関数には、どのようにエラーを伝えれば良いでしょうか。

下位の関数で発生したエラーを、そのまま上位の関数に受け渡すことも多いようです。例えば、次のようになります。

int bar ( ) {
                :
        int ret = foo();
        if (ret != XXX_OK) {
                return ret;
        }
                :
        return XXX_OK;
}
          

しかし、この方法では、関数 bar() を呼び出した時に、どのようなエラーが発生する可能性があるのかを、bar() を利用する側が把握できない、という問題があります。関数 bar() の利用者は、そこから呼び出される関数 foo() のことまで知らなくてはなりません。また、foo() や bar() の実装が変わるだけで、返されるエラーコードが増えて、呼び出し側まで修正する必要がでてくる可能性もあります。

これらの問題を回避するために、下位の関数で発生したエラーは破棄し、改めてエラーコードを返す、という方法が考えられます。例えば、次のようになります。

int bar ( ) {
                :
        int ret = foo();
        if (ret != XXX_OK) {
                return XXX_FOO_FAILED;
        }
                :
        return XXX_OK;
}
          

この方法なら、関数 bar() を呼び出したときにどのようなエラーが発生するかは、関数 bar() を見るだけで把握できます。

これは、C言語のエラーコードだけでなく、C++言語やJava言語の例外についても同じことが言えます。

特にC++言語では、投げられる例外を関数宣言に記述しないため、関数を呼び出す際に、何をキャッチすれば良いのか、まったく分からなくなります。それを避けるためには、それぞれの関数の中で、下位の関数から投げられる例外をすべてキャッチし、破棄した上で、改めて新たな例外を投げ直す、という方針は有効です。

Java言語の場合は、投げられる例外を宣言する必要がありますので、下位から投げられる例外をキャッチしなくても、このような問題は起こりません。但し、実行時例外については宣言しなくても構いませんので、注意する必要があります。

Java言語では、J2SE 1.4から、例外チェーンの仕組みが導入されました。下位の関数から投げられる例外を、別の例外に変換して投げ直す際に、下位から投げられた例外の情報も含めて、上位に渡すことができます。

エラー処理は何のため？

ここまで、エラーが発生した時に、どのようなエラーが発生したのかを呼び出し側に知らせる仕組みについて、考えてきました。しかし、そもそも何故、エラーコードの番号体系や、エラーハンドリングの方法について、このようなことを考えなくてはいけないのでしょうか。

エラー処理を行い、エラーについての情報を呼び出し側に伝える目的は、最終的には、発生したエラーについて、人にきちんと知らせるためです。即ち、エラーについて何らかの出力をすることが目的です。

エラーが発生した時には、必ず、エラーについての情報を何らかの形で出力し、人に知らせる必要があります。もし、その必要がないのであれば、エラーコードなどは考える必要がありません。単に、正常か異常かを返すだけで良いことになります。

人にエラーを知らせる方法

発生したエラーについて人に知らせる方法には、ソフトウェアの開発者に知らせるための方法と、利用者に知らせるための方法と、２つの種類があります。

ログは、主にソフトウェア開発者がデバッグを行うために、エラーの情報をファイルに出力するものです。クラス名や変数名、値、ファイル名、行番号などを、そのまま出力します。

エラーメッセージは、ソフトウェアの利用者にエラーが起きたことを知らせるために、コンソールやウィンドウに出力するものです。一般の利用者が見て分かるような表現で出力します。利用者がエラーを確認して何らかの操作を行うまで、ソフトウェアの動作を停止させるために、メッセージボックスを使うこともあります。

どこでエラーを出力するべきか？

では、これらの方法でエラーを出力する処理は、ソフトウェアのどこに記述すれば良いのでしょうか。

１つは、ある関数でエラーが発生した時、エラーの出力もその関数の中で行ってしまう、という方針が考えられます。ログの出力は、たいていはこの方針で行われます。

もう１つは、発生したエラーの情報を呼び出し側に渡して、エラーの出力は呼び出し側で行う、という方針も考えられます。エラーメッセージの出力は、たいていはこの方針で行われます。

この２つの方針には、それぞれ利点と欠点があります。

エラー処理がオブジェクト指向設計を破綻させる

エラーの出力に関しては、エラーが発生した関数の中で出力するにしても、呼び出し側で出力するにしても、いずれにせよ、設計上の問題が生じます。エラー処理を組み込むと、上位側と下位側の結合が密になったり、暗黙の了解が含まれたりして、せっかくオブジェクト指向的に考えた設計が破綻することにもなりかねません。

実際のソフトウェア開発では、開発の最終段階になってからエラーの出力を組み込もうとして、オブジェクト指向的な設計の形を崩すことが多いようです。汎用性を犠牲にして、ある特定の利用形態で適切なログが出力されるようにエラー処理を組み込んだり、エラーメッセージの表示仕様に基づいて、返すエラー情報の内容を決めたりすることが良くあります。

アスペクト指向プログラミングは解決策となるか？

最近のソフトウェア開発では、アスペクト指向プログラミングという考え方が流行しています。

エラー処理とログ出力は、アスペクト指向プログラミングの典型的な応用例として紹介されていることが多いです。ですが、これまでに述べたエラー処理とログ出力に関する問題は、本当にアスペクト指向プログラミングによって解決するのでしょうか？

アスペクト指向プログラミングとは、ソフトウェアの主要なロジック以外の処理を切り離すことで、本来の処理を明確にするという手法です。

エラー処理やログ出力のコードは、きちんと書いていくと、かなりの分量になります。業務用のソフトウェアでは、エラー処理のコードばかりになって、本来の処理が良く分からなくなってしまうことも、珍しくありません。エラー処理やログ出力を、ソースコードから切り離す、というのは、確かに魅力的なアイディアです。

ただ、そのアイディアの背景は、ソフトウェアの本来の処理と、エラー処理は、互いに独立で、分離させることができる、という前提があります。しかし私は、ソフトウェア本来の処理とエラー処理は切り分けられるものではなく、むしろ、エラー処理の方法もソフトウェアのデザインの一部と考えるべきではないか、と思っています。

エラー処理の理想を追い求めて

エラー処理とログ出力に関する問題は、これらを無視して設計したソフトウェアに、後からこれらの仕組みを継ぎ足そう、としていることが大きな原因になっています。一貫したソフトウェアを構築するためには、初期の段階からエラー処理まで含めて設計すべきではないか、と思います。

もちろん、どのような方法でエラーを処理し、どのような仕組みでログを出力するのかは、良く考える必要があります。エラー処理やログ出力のコードで、本来の処理が分かりにくくなってしまった、というケースは、クラス設計がうまくできておらず、機能や役割がうまく分担できなかった場合と、同じ状況に陥っていると言えます。

実際のアプリケーションの開発では、エラーの判定やエラー処理だけを、独立したクラスに分離する、ということも良くあります。エラー処理やログ出力を行う専門のクラス群を作る訳です。この場合、これらのクラス群と、ソフトウェア本来の処理を行うクラスとの結合をできるだけ疎にすることが理想的です。

これがうまくいけば、ソフトウェア本来の処理と、エラー処理やログ出力を、見事に切り離すことができたように見えることでしょう。アスペクト指向プログラミングが目指した理想の形は、エラー処理やログ出力まで含めたソフトウェア全体の設計をうまくデザインすることでこそ、実現できるのではないか、と思います。

ログを出力する際の注意

ログには、エラーの原因となった変数の値をそのまま出力することが多いです。しかし、エラーが発生した時の値は、不用意に出力するべきではありません。

これらのことに注意しないと、肝心のエラーが発生した時に、ログが出力されない、という状況になってしまいます。

ログに出力しておくと役立つ情報

ログには、次のような情報も出力しておくと役に立ちます。

• 実行ファイルやライブラリのパス。
• 実行ファイルやライブラリのサイズ、日付。
• 実行ファイルやライブラリのバージョン。

たびたび修正を行ったり、バージョンアップを繰り返しているソフトウェアでは、問題が発生した時のために、ソフトウェアがいつの時点のもので、どのような修正が施されているかを分かるようにしておく必要があります。

次のように、個々の障害番号や修正番号ごとに、それが修正されている旨をログに出力する、という方法も考えられます。

XXX_0001 fixed.
XXX_0002 fixed.
XXX_0004 fixed.
          

アサートの罠

ソフトウェアを開発する際に、アサートを多用する人も多くいます。しかし、アサートはエラー処理の仕組みではないので、注意が必要です。

アサートは、テスト工程で不具合を見つけるための準備です。いわば、テストコードの一種と考えられます。

アサートは、ソフトウェアが正しければ本来はあり得ない状態になったことを検出するものです。アサートの仕組みは、このような誤りをテスト工程ですべて見つけられる、という仮定に基づいています。

しかし、万が一、ソフトウェアの誤りが見逃されてしまったら、どうなるでしょうか。通常、リリース用の実行ファイルには、アサートの処理は含まれません。すると、万が一のことが起きた場合は、アサートを入れた箇所は素通りし、ソフトウェアは暴走することになります。

もし、万が一の場合でも暴走しないようにするためには、アサートではなく、ソフトウェアが確実に停止するように、きちんとエラー処理を組み込む必要があります。