NAL-6295の舌先三寸 - 人工衛星は日々落下する。そして、ジェット噴射する。 ASP.NETにおけるエラーハンドルの説明
まぁ、そんなわけで、私が書いているコードはほとんどTry-Catch-Finallyではなく、Try-Finallyばかりだ。 正当な理由がある（Catchする事に意味がある。）時や、付加情報を付けて再Throwしたい時くらいしかcatchしない。 では何処でcatchしているかというと、global.asaxのApplication_Errorイベント内。 ここに例外が飛んできたら、イベントログに、その内容を書き出してDebugモード時は画面にも例外の内容を、Releaseモード時は「ご迷惑をお掛けしています。」ページに遷移するようにしている。 では、なぜむやみにcatchしては駄目かと言えば、 正当な理由がないのにcatchして例外を消してしまうと、一見うまく行っているような動作をしてしまう そのため傷口がどんどん広がる。 そのためバグが発覚しにくい。 発覚した時には手遅れになっている
C#と諸々 業務エラーの表現方法 再び
まず最初に謝ります。ごめんなさい、以前 業務エラーの表現方法の考察 で書いたことを取り消させてください。 僕はやはり、 「業務エラーは例外で表現するべき」 と考えます。 では、その理由について語っていきます。 【 目次 】 1. 例外の利点 4. まとめ 5. 参考文献 【 用語 】 この記事で使用する用語について、以下のように定義します。 ・例外 System.Exceptionから派生する全ての例外クラスを指します。 ・エラー 正常系ではないフローを指します。エラーは業務エラーとシステムエラーに大別できます。 ・業務エラー エンドユーザーの操作次第で発生しうるエラーを指します。 業務を遂行する上で間違った操作をエンドユーザーが行った場合に発生するエラーや、エンドユーザーが操作を行っている間に、他のエンドユーザーが何らかの操作を行ったことによって、現在の操作が有効でなくなった場合に発生す
はてなブログ | 無料ブログを作成しよう
吹奏楽コンクール リウマチの調子が悪い！薬の副作用もやばい！ 副作用のせいでご飯が全然食べられなくなって顔から痩せていくんだけど、お腹とかお尻から痩せたらいいのに。蓄えがあるから多少痩せたってちょうどいいくるいやけど、幸薄そうに見えるから顔は太ったままがいいなぁ。 お…
C++でコンストラクタから例外を送出したい時 - 足跡
きっと今年最後の思いつき。 一般にコンストラクタから例外を投げるとリソース漏れの危険性が出てくる。 例外を投げた当のオブジェクトが自身のリソースをきちんと処理していなかったり、コンストラクタから例外を投げるクラスをnewした時にインスタンスが宙ぶらりんになっちゃったり。 なのでリソース漏れが嫌ならコンストラクタから絶対に例外を投げないようにすべき。 だがそうすると今度はpublicなエラーチェックメソッドを設ける必要が出たり、空のオブジェクトが存在する事になってしまったりする。 そうすると色々手間が増えてしまったりスマートさが無くなって残念な気持ちになってしまう。表 --- 追記ここから --- コンストラクタから例外を投げる時、そのクラスがnewされたならインスタンス用に割り当てようとした領域は自動で破棄されるらしい。デストラクタ呼ばれないけど。 破棄されるっていう記述も破棄されないって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
