このメソッドから例外をスローする必要がありますか？

Question

メソッドでいくつかのパラメータの検証を行い、必要に応じて例外をスローします。このタイプの例外を手動でスローする必要がありますか？呼び出し元がtry..catchブロックにラップされている限り、手動チェックが適所にあるかどうかにかかわらず、同様の例外がスローされます。

public static Int16 ToInt16(this byte[] value, int startIndex, bool isBigEndian) { 

     // are these exceptions necessary? 
     if (value == null) { 
      throw new ArgumentNullException("value"); 
     } 

     if ((startIndex + 1) >= value.Length) { 
      throw new ArgumentOutOfRangeException("startIndex"); 
     }  

     return (isBigEndian) 
      ? (Int16)((value[startIndex] << 8) | value[startIndex + 1]) 
      : (Int16)((value[startIndex + 1] << 8) | value[startIndex]); 
    } 

これは、ビッグエンディアンまたはリトルエンディアン変換を切り替える方法でInt16型にアレイ状に2つのバイトを変換するために使用される拡張メソッドです。

Answer 1

ここで例外をスローするのは、nullのderef例外を取得するのではなく、最も重要なことに引数が無効であることを示す引数例外を取得することです。例外は、何かの可能性のある一般的なnull derefよりも、より明示的に原因を指しています。

これは既に間接的なレベルの拡張メソッドであることを考えると、完全であり例外を含めるほうがおそらくもっと便利だと思います。特にあなたは明らかにそれを書いてきましたが、政策上の問題でさえあります。それが拡張メソッドでなければ、私はいずれかの方法で行くことができます。私はまた、コードがどのように埋め込まれているかによって、代わりにアサーションを使用するかもしれません。

現在のところわかりませんが.Net 1.1と1.0のフレームワークでは、JITコンパイラは、スローされた呼び出しをインラインにしません。これを回避するには、例外自体をスローする別のメソッドを作成することがよくあります。

ところで、startIndex + 1> value.Lengthで1つずつエラーが発生します。代わりに> =にする必要があります。

Answer 2

DotNET Frameworkコード（Reflectorを使用して）を見ると、MSの人はこれらの例外を手動でスローすることがわかります。

サードパーティのプログラマが頻繁に使用するSDKを作成している場合は、少なくともトップレベルの機能でArgumentNullExceptionsをスローすることをお勧めします。

Answer 3

クラスライブラリの設計ガイドラインに従って、タイプのパブリックメンバーのすべてのパラメータを検証する必要があります。 http://msdn.microsoft.com/en-us/library/8ey5ey87(VS.71).aspx

---

UPDATE：新しいバージョン：http://msdn.microsoft.com/en-us/library/ms229007.aspx

Answer 4

私の意見はあなたが例外をスローする必要があることです。私の考えは、他のプログラムやこのプログラムの他の部分で使用されているライブラリの一部になる再利用可能なコードを構築しているようです。現在のコードで適切な例外処理を使用している可能性がありますが、将来このメソッドを使用する他の人が適切な例外処理を実行する保証はありません。もう1つ考慮すべきことは、メンテナンスでは、このメソッドの実装が変更される可能性があり、問題を捕らえずにすぐに例外をスローすることがどのような意味を持つかについて考える必要があります。私はあなたが上記のコードは大丈夫だと思いますが、私は通常、より明示的なメッセージを提供します（もちろん、それは私の好みであり、あなたがやっていることはまだその問題を伝えています）。他のプログラマがするので

ジョー

Answer 5

パブリックメソッドを書いているときはいつでも、あなたはブラックボックスのように扱う必要があります。

次の2つの方法で、理解しやすいですMethodA（I int型）とMethodB（I int型）を、持っていた場合は？

• MethodA（1000）がArgumentOutOfRangeException
• MethodB（1000）スローはMethodAIndexOutOfRangeException

をスローする方法のコードを開くことなく固定することが容易です。 MethodBは、引数と無関係の理由でその例外をスローしている可能性があります。そのため、メソッドにデバッグして何がうまくいかないかを判断する必要があります。