というわけで、前回まで 3 回（＋α）に渡って .NET の例外処理の適切な書き方について解説してきましたが、ここまでの解説にもまして重要なのは、 表示またはロギングされた例外情報を、正確に読み取れるようになること。 です。実は例外に含まれる情報には、デバッグや障害解析に欠かせない情報が多数含まれており、これらを正しく読めるようになるだけで、以下のようなことがわかることが多いのです。 どこで例外が発生したのか アプリケーションの内部構造がどんな形になっているのか 例外がどんなシチュエーションで発生したのか...

さて、前回までの解説で、.NETアプリケーションにおける一般的な例外の取り扱い型の基本を学習してきました。キーポイントをまとめると、以下の通りです。 例外は、アプリケーションエラーやシステムエラーの場合に限り、利用する。 例外は、基本的にユーザアプリケーション内ではtry-catchをせず、ランタイムの持つ集約例外ハンドラの機能によって後処理する。 というわけで今回解説をするのは、ASP.NET ランタイムが持っている集約例外ハンドラの機能についてです。（基本的にはこれを学習すれば、Windows...

さて、ここまで .NET における例外処理の基本的な考え方として、次のようなポイントを解説してきました。 .NET では、「業務フローチャートからはみ出た場合」 を表現する方法として、例外を使う。 業務フローチャート上想定されている業務エラーを、例外として表現してはいけない。 業務エラーは、メソッドの戻り値として enum 型や構造体クラスなどを使うことで表現する。 これらの考え方は非常に重要なのですが、実はこのような例外の取り扱い方は、Java における例外の取扱い方とは大きく異なります。これは...

さて今度は ASP.NET ランタイムの例外処理について解説……しようかと思ったのですが、ここで例外処理について、もうちょっとツッコミを入れておきたいポイントがあります。それは、以下の 2 つです。 リソース解放のための try-finally 処理 Java の例外と .NET の例外の違い この 2 つは実は例外処理コードを正しく書く上では欠かせない概念なのですが、世の中に出回っているサンプルコードでもこれらの点が正しく理解できていないために、誤ったコードが多数見られます...