.Net が提供するものを使用するのではなく、いつ独自のカスタム例外クラスを作成する必要がありますか?
どの基本例外クラスから派生させる必要があり、その理由は?
.Net が提供するものを使用するのではなく、いつ独自のカスタム例外クラスを作成する必要がありますか?
どの基本例外クラスから派生させる必要があり、その理由は?
独自の例外を作成する理由
独自の例外を作成して、それらをスローしたときに特定のキャッチを取得して、システムがスローした (未処理の) 例外と区別できるようにします。
どのクラスから派生させる必要がありますか?
以前は、カスタム例外をApplicationException
クラスから派生させることが標準的な方法でしたが、時間の経過とともに MS の推奨事項が変更され、開発者はクラスから派生するのSystem.Exception
ではなく、それ自体から派生するようになりました。ApplicationException
例外処理の目標は、何が問題なのかを明確に理解することです。したがって、提供された例外で明確な理解が得られない場合は常に、独自の例外を定義する必要があります。
たとえば、アラビア数字をローマ数字に変換するアプリケーションを書いています。このアプリケーションの制約の 1 つは、ローマ数字が 0 < x < 4000 の範囲内に収まる必要があることです。
private string ToRoman(int number)
{
if (number > 0 && number < 4000)
{
//ConvertHere
}
else
{
//Custom exception used for readability purposes.
throw new NumeralOutOfRangeException();
}
}
どの基本クラスを使用するかについては、Microsoft はユーザー定義の例外を Exception のサブクラスにすることをお勧めします。( http://msdn.microsoft.com/en-us/library/seyhszts.aspx )
これは少し明白に思えるかもしれませんが、組み込みの例外が意味をなさない場合は、例外を作成する必要があります。通常、作業中のライブラリの基本例外を定義します。
public class MyLibraryException : Exception
{
// .....
}
次に、ライブラリを使用するときに発生する可能性のある状況の例外を作成します。
public class SomethingHorribleException : MyLibraryException
{
// .....
}
そうすれば、クライアントは、私のライブラリが継承するものをスローすることを常に知ることができますMyLibraryException
。
独自の例外を作成する理由の 1 つは、それらを分離してキャッチできるようにするためです。例えば:
try {
// do stuff
} catch (MyCustomException e) {
// handle this known exception
}
他のすべての例外はバブルアップし、別のレベルで処理できます。
これまでの回答はすべて良さそうですが、次のことも追加します。
これらの例外を処理する必要があるために公開される可能性のある実装の詳細を非表示にするため。
たとえば、UI で SQLException をキャッチしたくありません。データ アクセス コードから独自の例外をスローし、UI でそれらを処理できるようにする必要があります。データ ストレージ (XML、ファイル システムなど) をデータベース以外のプロバイダに変更した場合、UI コードを変更する必要はありません。
ただし、UI コードで明示的に処理している場合にのみそうします。
変数、場所、ユーザー名、返されたレコードの数など、他のプロパティを追加したい場合は、独自の例外クラスを作成します。
基本的に、エラーの内容とその再作成方法を絞り込むクラスを作成します。
編集
ああ、エラーを表示するためにフロントエンドに渡すことができる例外クラスに検証エラーを追加できます。