Visual Studio 2008 でまた勉強になった。

Visual Studio 2008 でデバッグすることは多いですが、
ソースの作り方が下手糞だと、

・例外の握りつぶし(隠蔽)
・throw の失敗(http://blog.goo.ne.jp/tbinterface/494960f5e490576c6f80dfe2366c98ef/72)

をやってしまって、出力ウィンドウには例外が出力されてるのに、実際に例外が発生した箇所がわからない事があります。


そんな時にはこの設定をして、例外が発生した箇所を特定しましょう。

1.ツールの「デバッグ → 例外」例外ウィンドウが開く
2.「Common Language Runtime Exceptions」のツリーを展開(.NETの場合)
3.出力ウィンドウに出ている、発生している例外クラスを探す
  例:System.FormatException の場合、
    「System」ツリーを展開
    「System.FormatException」って言うのが居ます。
(右の「検索ボタン」からでもOKです)

4.右のチェックボックスにチェックをつける。
5.OKボタンを押下する。


この手順を行うことで、握りつぶしだろうが、なんだろうが、
例外が実際に発生した行で止まります。
強制的に止まります。
何度でも止まります。
ウザイほど止まります。

ブレイクポイントと同じなので、そこからデバッグできるし、
変数内容も確認できます。
いやぁ~~便利♪

チェックをはずせば元に戻ります。



この例外出てて良いのかなぁ~~?
って疑問に思った時はコレッ!
出て良い例外なのか、出ちゃいけない例外なのか判断できます。







ちなみに、私の思想としては
【自作以外の例外なんて1件も出すんじゃない。例外前にチェックして回避せよ】
です。

ネットを見ると「(処理が面倒?)例外にしちゃえば良いじゃん。」って書き込みを良く見ますが、
出てよい例外と出てはいけない例外の区別が付かなくなるので嫌いです。

ちなみに、例外クラスを自作して、自作例外クラスをthrowするのは良いと思います。
事前チェックして処理できないなら自作例外クラスをthrowすべきです。

コメント

このブログの人気の投稿

ヨドバシカメラの店舗購入履歴を見るには…

C# の WPF の DataGrid で 行を交互に背景色を変える+選択色を変える+カラムが無い所も変える…

Visual Studio の ホットリロードが動かない場合に確認するところ