菊池 Blog - 今週のクラス System.Exception
目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 386 記事 - 16 コメント - 576 トラックバック - 104 ニュース BlogRollするぐらいならトラックバックしてこい。 記事のカテゴリ .NET Framework オブジェクト指向 プログラミング全般 過去の記事 2008年9月 (3) 2008年8月 (1) 2008年7月 (1) 2008年6月 (3) 2008年5月 (2) 2008年4月 (1) 2008年3月 (1) 2008年2月 (20) 2008年1月 (8) 2007年12月 (16) 2007年11月 (2) 2007年9月 (3) 2007年8月 (1) 2007年7月 (5) 2007年6月 (1) 2007年5月 (
NAL-6295の舌先三寸 - 人工衛星は日々落下する。そして、ジェット噴射する。 ASP.NETにおけるエラーハンドルの説明
まぁ、そんなわけで、私が書いているコードはほとんどTry-Catch-Finallyではなく、Try-Finallyばかりだ。 正当な理由がある（Catchする事に意味がある。）時や、付加情報を付けて再Throwしたい時くらいしかcatchしない。 では何処でcatchしているかというと、global.asaxのApplication_Errorイベント内。 ここに例外が飛んできたら、イベントログに、その内容を書き出してDebugモード時は画面にも例外の内容を、Releaseモード時は「ご迷惑をお掛けしています。」ページに遷移するようにしている。 では、なぜむやみにcatchしては駄目かと言えば、 正当な理由がないのにcatchして例外を消してしまうと、一見うまく行っているような動作をしてしまう そのため傷口がどんどん広がる。 そのためバグが発覚しにくい。 発覚した時には手遅れになっている
匣の向こう側 - あまりに.NETな#p1
仕事上ではC/C++を使っていて、エラー処理等は全て戻り値でやっているのですが、.NETだとクラスライブラリが例外を返してくるので、例外処理付き合わざるを得ません。私の例外処理に対する知識は10年以上前にC++の勉強で身につけたものでして「例外はあくまでも例外。通常は起こるはずが無いもの」となっています。しかし、「OSの異常」みたいなのだと話は簡単なのですが「業務上あり得ない」とかになってくると境界が曖昧になって悩みます。 それはさておき、メソッドが例外を返すとされている場合、 呼び出し側のミス(nullを渡すな等) メソッド内部で起こった異常 と、大ざっぱに分けられます。1.はバグなので出荷時には潰されているべきものでしょう。さて、2.については、呼び出し元の責務によって対応が変わってきます。 例外処理をどう扱えば良いか、イマイチよく分かっていないので、現在、自分が考えていることをつらつ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
