2

例外をスローするコンポーネントを作成しました。標準に固執するthrow new Exceptionか、特定の例外を作成するかを考えています。

また、Remoting または WCF から例外をスローする場合、ユーザー定義の例外は魅力的ではないと考えています。標準例外を使用すると、呼び出し元は例外を受け取ることができます。ユーザー定義の例外を作成した場合、コンポーネントのアセンブリもクライアントにデプロイされていない限り、呼び出し元は特定の例外を受け取ることができません。ただし、Remoting および WCF 内からユーザー定義の例外をキャッチし、それを標準の例外として再スローすると、クライアントはユーザー定義の例外から例外を受け取ることができます。これにより、ユーザー定義の例外の目的が無効になります。

ユーザー定義例外の追加があまり役に立たないのはいつですか?

[編集]

私の考えを共有すると、ユーザー定義の例外はコンポーネントで (少なくとも 1 つ) 必須であると思います。そのため、独自のコンポーネントを単体テストする場合、誤検知は発生しません。

これにより、誤検知が発生します。

[Test]
public void Tag_is_missing()
{

    string message = "";

    try
    {
        // Arrange  
            // this will fail on *nix systems       
        MyComponentHelper.ParseXml("C:\A.XML");
    }
    catch(Exception ex)
    {
        // Act
        message = ex.InnerException.Message;
    }


    // Assert
    // How can we be sure that the word "not found" error is from 
    // xml parsing or if from file loading? Doing Pokemon exception handling
    // will lead to ambiguities
    Assert.IsTrue(message.Contains("not found"));

}

独自の例外を作成しなかった場合、単体テストで誤検知が発生する可能性があります。「見つかりません」という文字列は、コンポーネントまたはコンポーネントの他のサブシステムからのものである可能性があります。したがって、ユーザー定義の例外をいつ作成する必要があるかという私のケースがあります。

これにより、誤検知は発生しません。

[Test]
public void Tag_is_missing()
{

    string message = "";

    try
    {
        // Arrange     
        // this will fail on *nix systems        
        MyComponentHelper.ParseXml("C:\A.XML");
    }
    catch(XmlParsingException ex)
    {
        // Act
        message = ex.InnerException.Message;

        // Assert
        // And now we are more sure that the error didn't come from
        // program subsystem; in particular, file subsystem.
        Assert.IsTrue(message.Contains("not found"));
    }


}

考えなければならないことは、非常に具体的なユーザー定義の例外を作成する必要がある場合です。今のところ、最初に、コンポーネントに対してユーザー定義の例外を 1 つだけ設定することに決めます。単体テストで誤検知が発生することはありません。

4

3 に答える 3

2

標準の例外 (.NET によって提供される) では例外条件に関する十分な情報が得られないと思われる場合は、カスタム例外を使用します。このカスタム例外では、メッセージ文字列だけでなく、例外に関する詳細情報を提供するプロパティを提供できます。

カスタム例外は、システム例外の単なるラッパーです。元の例外情報は、カスタム例外の InnerException プロパティにあります。

例外クラスは次のように設計できます。


public class NewException : BaseException, ISerializable
{
    public NewException()
    {
        // Add implementation.
    }
    public NewException(string message)
    {
        // Add implementation.
    }
    public NewException(string message, Exception inner)
    {
        // Add implementation.
    }

    // This constructor is needed for serialization.
   protected NewException(SerializationInfo info, StreamingContext context)
   {
        // Add implementation.
   }
}

カスタム例外をスローするときは、次を使用します。


try
{
   .....
}
catch(ArgumentNullException argumentNullException)
{
   throw new NewException("This is a custom exception message", argumentNullException);
}

System.Exceptionさらに、最上位のコントロール クラスでのみベースをキャッチすることをお勧めします。内部クラスでは、特定の例外タイプをキャッチし、必要に応じてカスタム例外を使用する必要があります。

詳細については、次を参照してください。

于 2010-12-28T02:24:53.940 に答える
0

例外のトラップは非常に一般的であり、コンポーネントの他の領域によって (前述のように) 他の予期しないエラーをマスクする可能性があります。プロパティまたはその他のメッセージの使用はオプションです。

ただし、私が見つけた最も効果的なアプローチは、Exception のサブクラスである標準例外の 1 つをスローすることです (例: ArgumentOutOfRangeException); それらが十分に正確ではなく、何かをスローする必要がある場合は、サブクラスを作成してそれをスローします。

また、例外は例外的なケースであることにも注意してください。例外をスローするのは理にかなっていますか、それとも何らかの値 (エラー コードを意味するものではありません) を返す方が適切でしょうか?

于 2010-12-28T02:33:07.350 に答える
0

ユーザー定義の例外は、内部プロジェクト開発で問題を適切に解決する場合にのみ意味があると思います。

于 2010-12-28T01:32:05.320 に答える