4

次のようにカスタム例外を実装することの長所と短所は何ですか。
説明にエラーメッセージを表す列挙型を作成します。 

public class Enums
{
    public enum Errors
    {
        [Description("This is a test exception")]
        TestError,
        ...
    }
}

カスタム例外クラスを作成します。 

public class CustomException : ApplicationException
{
    protected Enums.Errors _customError;
    public CustomException(Enums.Errors customError)
    {
        this._customError = customError;
    }
    public override string Message
    {
        get
        {
            return this._customError!= Enums.Errors.Base ? this.customError.GetDescription() : base.Message;
        }
    }  
}

このGetDescriptionメソッドは、リフレクションを使用して列挙型の説明を取得する列挙型拡張メソッドです。このようにして、次のような例外をスローできます。 

throw new customException(enums.Errors.TestError);

そして、次のようなキャッチブロックでユーザーに表示します。

Console.WriteLn(ex.Message);

私はこのアプローチがMVPによって推奨されているのを見てきました。次の点に対するこのアプローチの利点は何ですか。

  • 一般的な例外の使用：throw new Exception（ "Error Message"）;。
  • カスタム例外の使用：あらゆる状況でカスタム例外を定義します。例（WebServiceExceptionクラス、AuthenticationExceptionクラスなど）

MVPによる推奨へ のリンクは次のとおりです。

ありがとうございました。

4

5 に答える 5

5

個人的には、それは良い考えではないと思います。

できるだけ具体的な例外を常にスローする必要があります。キャッチングも同様です。

WebServiceExceptionまたはをキャッチするかどうかを決定するのは簡単ですAuthenticationExceptionが、列挙型の例では、文字列を解析してキャッチするかどうかを決定する必要があります。このメッセージが変更されるとどうなりますか?

メリットは全くないと思います。エラーの種類ごとに、新しい Enum メンバーを作成する必要があります。代わりに、新しいクラスを作成してみませんか?

于 2011-06-10T17:56:15.690 に答える
3

カスタム例外の主な利点は、さまざまな例外の種類を区別するための言語サポートです。例えば

try 
{
    SomeFunc()
}
catch( CustomException EX)
{
    //This is my error that I know how to fix
    FixThis()
    DoSomeAwesomeStuff()
}
catch( Exception exa)
{
    //Somthing else is wrong 
    WeepLikeBaby();
}

メッセージプロパティを使用する場合

try 
{
    SomeFunc()
}
catch( Exception exa)
{
    if(exa.Message == "ErrType 1")
    {
        DoStuff;
    }
    if(exa.Message == "ErrType 2")
    { 
         Die();
     }
}

Base enum の例を利用しても、この機能を保持できます。ただし、メッセージを定義する 1 つの場所を自分自身に与えますが、それはアプリケーションによってさまざまな方法で解決されます。列挙型の例は、メッセージ文字列を個別に定義する方法を提供するため、ローカライズされたメッセージの作成を非常に簡単にします。

もう 1 つの利点は、アプリケーションで意味のある Cusotm データを追加できることです。たとえば、顧客情報システムがあり、ほとんどの場合、顧客 ID が重要になるとします。メッセージ プロパティのみを使用する場合、すべてのハンドラーは、必要に応じてその情報を解析する方法を認識している必要があります。

public class MyCustomeEx : Exception
{
    int CustID { get; set; }
}

public void Fail()
{ 
    //Awww Customer error
    throw new MyCustomeEx () {CustID = 123}
}
于 2011-06-10T18:03:26.140 に答える
2

MVPの推奨事項へのリンクはコメントで共有されました。

コードと質問を見た後、これの理由は、例外で可能なメッセージを制限するためだと思います。また、例外テキストのローカライズに役立つかもしれませんが、この例では追加の作業が必要です。とにかく、そのようなメソッドは、異なる方法で処理される「例外サブタイプ」を作成するために使用されるべきではありません。

于 2011-06-10T18:09:22.667 に答える
2

オプション 1 お勧めしません。絶対に投げてはいけませんSystem.Exception。コードで合理的に構造化された例外処理を行うために、状況に応じて利用可能な最も具体的な例外を常にスローする必要があります。

提案された方法 ( ) に見られる主な欠点はErrors enum、最初に例外をキャッチすることなく、例外を処理するかどうかを決定する方法がないことです。カスタム例外を使用すると、事前にその決定を行うことができます。

于 2011-06-10T18:02:56.627 に答える
2

次の同様のスタック オーバーフローの質問で私の (受け入れられた) 回答を参照してください: Custom exception vs built in exception with very descriptive message。軽薄なカスタム例外に対する引数を提供するのに役立つはずです。

于 2011-06-10T18:05:08.637 に答える