5

msdn linkには、
System.ExceptionまたはSystem.SystemExceptionをスローしないように記載されています。
私のコードでは、私はこのように投げています

private MsgShortCode GetshortMsgCode(string str)
        {
            switch (str.Replace(" ","").ToUpper())
            {
                case "QNXC00":
                    return MsgShortCode.QNXC00;
                default:
                    throw new Exception("Invalid message code received");
            }
        }

これは悪い習慣ですか？

4

3 に答える 3

9

一般的に、より明確にすることができます。

この場合、あなたは投げることができます

ArgumentException

具体的であればあるほど、他のコードが例外を処理しやすくなります。

これにより、次のことが可能になります

try
{
    GetshortMsgCode("arg")
}
catch(ArgumentException e)
{
    //something specific to handle bad args, while ignoring other exceptions
}
于 2012-11-27T13:30:51.430 に答える
3

この特定のインスタンスでは、をスローする必要がありますArgumentException。

特定の例外タイプの主なポイントは、呼び出し元の観点からそれについて考えることです。両側の実装の詳細を理解しているので、呼び出し元のコードも記述している場合、これは実際にはかなり注意が必要です。ただし、発信者に何か間違ったことをした場合にどうなるかを明確に理解するのに十分な情報を発信者に提供する方法を常に考えてみてください。

この場合、単にスローExceptionすることは、エラーメッセージを解析して、何が間違っているかを理解する必要があることをArgumentException意味しますが、スローすることは、無効なものを渡したか、正しく実行できなかったことを、試行/キャッチでより簡単に区別できることを意味します。他の理由。

于 2012-11-27T13:34:53.520 に答える
1

状況によってはほとんどすべてが正しいので、「悪い習慣」のような用語を使うのは気が進まない。ただし、通常は、状況に応じて存在する最も具体的な種類の例外をスローすることをお勧めします。特定の例外が存在しない場合は、例外を定義する必要があります。

その理由は、をスローExceptionすると、呼び出し元は、発生しているエラーと、コードへの呼び出し中にシステムによってスローされた可能性のあるその他の例外を区別できないためです。

多くの場合、呼び出し元は他の問題とは異なる方法で例外を処理することを決定するか、少なくとも、例外が発生したことを知っている特定のメッセージをログに記録する可能性があります。例外を他の例外と簡単に区別できない場合、呼び出し元がそれを達成するのは困難です。

于 2012-11-27T13:36:47.547 に答える