例外によるエラー処理は最後に

ソフトウエアを作成するに至りエラー処理は重要である。いや、ソフトウエア以外でもそうであるかもしれないけどとにかく重要である。これがしっかりしているかどうかでプロかアマチュアの差が出る(ぇ　どんなに高性能で使い勝手がよくても、一度落ちる現象が起こっただけでもかなり評判がわるくなるなんてざらにある。そんなわけでエラー処理は重要である。

しかし重要と言っても最初から作りこむというのはあまりよくない気がする。特に例外を利用したエラー処理の場合は最初はあまり作りこまない方がよいのでは？と思う。極端な話、正常系だけ全部作っちゃってそのテストが終了してからエラー処理部分を作りこむという方法もありかもしれない。まあ実際にこの作り方やっちゃうと納期が迫って異常系が全然なままでリリースとかなっちゃう可能性があるからあまり現実的ではないかもしれないけど・・・。

エラー処理は例外を使うと便利である。私はC++でしか作りこんだことがないので他の言語はよく知らないけど、モジュールの入り口にtry〜catchを仕掛けるというのをよくやる。

try{
	//なんだか重い処理。
}
catch( const std::bad_alloc& ){
	〜
}
catch( 〜 ){
	〜
}

//まあいろいろcatchがあって・・・

catch( ... ){
	〜
}

ここで、最後の catch(...)が曲者である。この部分はいつもリリース直前に入れる。開発中は入れない。なぜかというと、これは例外すべてをキャッチしちゃうからだ。リリース時には予想していない例外でも受け取れるようにとあくまで「救済」が目的なのだが、開発中だと普通にバグで投げられた例外まで受け取ってしまう。なので、バグに気が付かないことがある。catchされなければハンドルされないから落っこちるのでデバッガで追っかけてやれば容易に見つけられるかもしれないのに。
そもそも catch(...)自体があまりよくないのかもしれない。バグに限らず、本来ここで拾うべきでない例外(もっと上で拾う予定だった)まで拾ってしまい適切な処理が出来ない可能性があるからだ。C++ではないが、javaでも何処かの書き込みに「catch( exception e )は最悪」みたいなのを見かけたことがる。理由はよく分からなかったけど多分今回のことと同じような内容だったんじゃないかと思う。

とりあえず、会社の同僚がいつまでもバグが見つからずに悩んだ原因でした（＾＾；