6

拡張メソッドがあるとしましょう

public static T TakeRandom<T>(this IEnumerable<T> e)
{
    ...

引数eを検証するには、次のようにする必要があります。

A）if（e == null）throw new NullReferenceException（）
B）if（e == null）throw new ArgumentNullException（ "e"）
C）チェックしないe

コンセンサスは何ですか？

私の最初の考えは常に引数を検証することなので、ArgumentNullExceptionをスローしました。繰り返しになりますが、TakeRandom（）はeのメソッドになるため、おそらくNullReferenceExceptionになるはずです。しかし、それがNullReferenceExceptionである場合、TakeRandom（）内でeのメンバーを使用しようとすると、とにかくNullReferenceExceptionがスローされます。

たぶん、Reflectorを使用してピークに達し、フレームワークが何をするかを調べる必要があります。

4

3 に答える 3

11

ArgumentNullExceptionをスローする必要があります。引数の検証を行おうとしているため、引数の検証に合わせて例外をスローする必要があります。NullReferenceExceptionは、引数検証の例外ではありません。ランタイムエラーです。

拡張メソッドは、内部では単なる静的メソッドであり、そのように呼び出すことができることを忘れないでください。拡張メソッドでNullReferenceExceptionをスローすることは表面上は理にかなっているように見えるかもしれませんが、静的メソッドではそうすることは意味がありません。メソッドで呼び出し規約を決定することはできないため、ArgumentExceptionを選択することをお勧めします。

また、NullReferenceExceptionを明示的にスローしないでください。これはCLRによってのみスローされるべきです。通常はCLRによってのみスローされる例外を明示的にスローするときに発生する微妙な違いがあります。

これも次の複製に近いです

于 2009-04-25T04:33:05.873 に答える
4

Enumerable LINQ演算子との一貫性を保つために、ArgumentNullException（NullReferenceExceptionではない）をスローします。

スタックトレースにより、null引数の指定に反対するのはTakeRandomであることが明らかになるため、TakeRandomメソッドで検証を行います。

于 2009-04-25T04:21:56.540 に答える
1

気が狂っているかもしれませんが、これは引数なので、ArgumentNullException をスローします:/

ただし、一般的な経験則は、可能であれば System.ApplicationException から派生した例外をスローすることです。NullReferenceException は、フレームワーク/CLR がスローするものです。

http://msdn.microsoft.com/en-us/library/system.exception(VS.71).aspx

基本クラス Exception の下には、次の 2 つのカテゴリの例外が存在します。

SystemException から派生した定義済みの共通言語ランタイム例外クラス。ApplicationException から派生したユーザー定義のアプリケーション例外クラス。

于 2009-04-25T07:17:23.670 に答える