2009年2月 3日 (火)エラー表示
おはようざいます。 本日の当番プログラマの、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だけするんじゃなくて、
一緒にトレースも忘れずにね。
こういうのって、
実際に直面して凹んではじめて、大切さが身にしみるのかもしれませんが、
皆さんも、何とかがんばってそうしてみませんか?
| 固定リンク | コメント (0) | トラックバック (0)
« もっと効率化 | トップページ | 自宅での過ごし方 »
「プログラマー」カテゴリの記事
- 技術交流の業(2019.03.07)
- 福袋争奪戦デビュー(2019.01.31)
- 温泉旅行(2019.01.24)
- ゲーセンの近況(2018.11.29)
- 健康的にプログラミングを続けるためのちょっとした習慣(2018.10.18)
この記事へのコメントは終了しました。
コメント