スタッフBLOG

おはようざいます。　本日の当番プログラマの、T.Yです。
ここ最近、つくづく思った事があります。

それは何かと言うと、処理が失敗したときのエラー処理です。

クラス全体として、失敗時は「-1」みたいなエラーのみで、
作ってしまっていた奴。
エラーのトレースは出す奴を作っていても、
それが各場所で呼び出される関数の中にあったり。

こいつらは、エラー出ても結局どこでエラーが出てるのか、
何が失敗したのか、わからない状態で
エラーが出た後に、何のエラーなのか突き止める作業がつきまといます。

普段発生しないバグとかで、折角発生させたのに、
出てるログが全く意味がない状態だったりしたときは・・・
泣きたくなります。。。。


そう言えば、昔の石油ファンヒーターとかは妙に丁寧でした。
液晶画面に何かエラー出てきても、
正面の蓋の後ろのラベルには、
エラー番号一覧とそれに該当する不具合のリストが。。
たとえば、
ER-93 燃料気化ユニットエラー、
ER-94 燃焼室温度異常、
ER-95 燃料ポンプエラー
ER-96 送風ファンモーターエラー
だとか、何が悪いのか教えてくれてましたのを、
すごく親切だなと思いました。


まぁ、最近の製品は、何のエラーでも、
とりあえず、Err99とかしか出てこないとかあったりしますが、

カメラだと、
・レンズの端子を拭いたら出なくなったとか。
・電池を入れ直したら出なくなったとか。。
・特に何もしてないけど、出なくなったとか。。。

接触が悪いの？　それともバグった？　とか
よくわからないままその表示が出なくなるとか。
正直こんなことされるとイラっとします。


でもこの辺の仕事って、デフォルトで終電とかザラだったりするので
過度の睡眠不足のダメージも蓄積され、意識が朦朧としている中。。
なかなかそんなところまで気が回らないもの事実。

でも、結局バグった時に、全てそれらの手抜きが蓄積された物が
一気に降りかかってくるので、結局は等価交換？
むしろ利子まで付いてきてる感じなので、最初からやっておくのが吉。


だから、デバッグ時には

void _FuncA( 引数 );

#if defined(_DEBUG)
void _FuncA( 引数, 呼び出し元ファイル名、行番号 );
#define FuncA( a ) _FuncA( a, __FILE__, __LINE__ )
#else
#define FuncA( a ) _FuncA( a )
#endif
※定義だけだけど、大体中身は察してください。


こんな風にして、デバッグ時用のオーバーライトした関数を用意して、
エラー時には、増やしてる引数のファイル名と、行数も一緒に出すと、
どこで呼ばれてる場所でエラーが起こってるのか分かります。


あとはエラー判定してる箇所で、returnだけするんじゃなくて、
一緒にトレースも忘れずにね。


こういうのって、
実際に直面して凹んではじめて、大切さが身にしみるのかもしれませんが、
皆さんも、何とかがんばってそうしてみませんか？