[.NET] Re: 例外について

kkamegawa 氏曰く、

新日々此何有哉: 例外について
2009-08-09

一つだけ重要なのは「例外発生した時の処理だけはちゃんとやっとこう」と。.NET Frameworkで発生した例外の画面を出しちゃうと、めっさ評判悪いのです。

基本的に賛成なんだけど、 それだけ言うと、 メソッドの中身を全部 try{…}catch(Exception ex){/* void */} で囲ってくれるヤツが出てくるんだよね。 全部捕まえて、 何もせず、 リスローもしない、 ってのが。 これはバグ隠しであって、 不具合の発見を遅らせ、 デバッグも困難になる、 悪いコードです。
# 「ヤツ」 ならまだしも。 コーディングルールに定めちゃうところまである始末。

.NET Framework には、 AppDomain.UnhandledException ( ⇒ MSDN マガジン 2008年 9月号 「CLR 徹底解剖 ～ CLR のハンドルされない例外の処理」 ) とか、 WinForm 用の Application.ThreadException ( ⇒ MSDN ライブラリ: Application.ThreadException イベント )やら、 ASP.NET アプリケーション レベルのイベント ハンドラ ( ⇒ MSDN ライブラリ ) といった、 上位でまとめてトラップする仕掛けが用意されてるので、 ログを書いてカスタムエラー画面を表示させるのは、 そこだけでやればいいんだよね。
※ まぁ、 そのへんの感覚は、 たぶん kkamegawa 氏も同じはず。

なので、 .NET プログラミングを始めたばかりの人には 「よほどのことがない限り、 try ～ catch するんじゃない」 「catch 句の中でリカバリ処理が書けるなら、 try ～ catch してもいい」 って言うわけです。
もっと知りたい人は、 「とあるコンサルタントのつぶやき : .NETの例外処理 Part.1」 ( 以降、 Part.2, Part.3, Part.4 ) あたりをどうぞ。
# 業務エラーを独自例外で表現してもいいじゃないか、 と思ってるので、 全面的に賛成ではありませんけど。 f(^^;

ついでに。 達人プログラマー 24 「いつ例外を使用するか」 ( すべての例外ハンドラーを除去しても、このプログラムは動作することができるだろうか? ) についても、 .NET Framework には業務的にはエラーじゃないのに例外を吐いてくれるオブジェクトがいっぱいある ( たとえば、 SqlException とか ) ので、 その基準は採用できないと考えています。
# 以前は int.Parse() とかも try ～ catch しなきゃしょうがなかったけど、 今は TryParse() があるので、 すこし幸せ f(^^;