無効なジェネリック型引数の最良の例外

私は現在、列挙型を処理するためのジェネリックメソッドを持つUnconstrainedMelodyのコードを書いています。

これで、「フラグ」列挙型でのみ使用することを目的とした一連のメソッドを持つ静的クラスができました。これを制約として追加することはできません...したがって、他の列挙型でも呼び出される可能性があります。その場合、例外をスローしたいのですが、どれをスローするかわかりません。

これを具体的にするために、私がこのようなものを持っている場合：

// Returns a value with all bits set by any values
public static T GetBitMask<T>() where T : struct, IEnumConstraint
{
    if (!IsFlags<T>()) // This method doesn't throw
    {
        throw new ???
    }
    // Normal work here
}

スローするのに最適な例外は何ですか？ArgumentException論理的に聞こえますが、これは通常の引数ではなく型引数であり、簡単に混乱する可能性があります。自分のTypeArgumentExceptionクラスを紹介する必要がありますか？使用しInvalidOperationExceptionますか？NotSupportedException？他に何か？

私はと思い、むしろそれが明確に行うには正しいことだがない限り、このために私自身の例外を作成していません。

NotSupportedException それは明白に適合しているように聞こえますが、ドキュメントはそれを別の目的に使用する必要があることを明確に述べています。MSDNクラスのコメントから：

基本クラスでサポートされていないメソッドがあり、これらのメソッドは派生クラスで実装されることが期待されています。派生クラスは、基本クラスのメソッドのサブセットのみを実装し、サポートされていないメソッドに対してNotSupportedExceptionをスローする場合があります。

もちろん、NotSupportedException特にその常識的な意味を考えると、明らかに十分な方法があります。そうは言っても、それが適切かどうかはわかりません。

無制限のメロディーの目的を考えると...

"T：enum"または "T：delegate"の型制約があるジェネリックメソッド/クラスで実行できるさまざまな便利なものがありますが、残念ながらC＃では禁止されています。

このユーティリティライブラリは、ildasm / ilasmを使用して禁止事項を回避します...

... Exceptionカスタムを作成する前に満たす必要のある証明の負担が大きいにもかかわらず、新しいものを準備する必要があるようExceptionsです。のようなものInvalidTypeParameterExceptionがライブラリ全体で役に立つかもしれません（そうでないかもしれません-これは確かにエッジケースですよね？）

クライアントは、これをBCL例外と区別できる必要がありますか？クライアントが誤ってこれをバニラを使用して呼び出す可能性があるのはいつenumですか？カスタム例外クラスを作成する際に考慮すべき要素に対する承認された回答によって提示される質問にどのように答えますか？

NotSupportedExceptionは回避します。この例外は、メソッドが実装されておらず、このタイプの操作がサポートされていないことを示すプロパティがあるフレームワークで使用されます。ここには収まりません

• 恥知らずな自己参照：http : //blogs.msdn.com/jaredpar/archive/2008/12/12/notimplementedexception-vs-notsupportedexception.aspx

InvalidOperationExceptionは、ここでスローできる最も適切な例外だと思います。

ジェネリックプログラミングでは、無効な型パラメーターが実行時にスローされません。コンパイルしないでください。コンパイル時の強制が必要です。何IsFlag<T>()が含まれているのかはわかりませんが、「フラグ」でしか作成できない型を作成しようとするなど、これをコンパイル時の強制に変えることができます。おそらくtraitsクラスが役立つでしょう。

更新

スローする必要がある場合は、InvalidOperationExceptionに投票します。その理由は、ジェネリック型にはパラメーターがあり、（メソッド）パラメーターに関連するエラーはArgumentException階層に集中しているためです。ただし、ArgumentExceptionに関する推奨事項では、

失敗に引数自体が含まれない場合は、InvalidOperationExceptionを使用する必要があります。

そこでの信仰の少なくとも一つの飛躍があり、そのメソッドのパラメータの推奨事項は、に適用されることもあり、一般的なパラメータが、のSystemException hierachyの私見では、より良いものはありません。

それはあなたが言っていることなので、私はNotSupportedExceptionを使用します。特定の列挙型以外の列挙型はサポートされていません。もちろん、これは例外メッセージでより明確に述べられます。

私は一緒に行きNotSupportedExceptionます。一方でArgumentExceptionルックスの罰金メソッドに渡された引数が受け入れられないとき、それは本当に期待されます。型引数は、実際の「引数」ではなく、呼び出す実際のメソッドを定義する特性です。InvalidOperationException実行している操作が有効である場合にスローされますが、特定の状況では受け入れられません。

NotSupportedException操作が本質的にサポートされていない場合にスローされます。たとえば、特定のメンバーがクラスにとって意味をなさないインターフェースを実装する場合。これは同様の状況のようです。

明らかに、Microsoftは、ExceptionsセクションArgumentExceptionのExpression.Lambda <>、Enum.TryParse <>またはMarshal.GetDelegateForFunctionPointer <>の例で示されているように、これを使用しています。私は、どちらか（ローカル基準ソースを検索するにもかかわらず、それ以外の場合を示す任意の例を見つけることができなかったTDelegateとTEnum）。

したがって、少なくともMicrosoftのコードではArgumentException、基本的な変数の引数のほかに、無効なジェネリック型の引数を使用するのが一般的な習慣であると想定しても安全だと思います。ドキュメント内の例外の説明はそれらを区別しないので、それはあまりにも多くのストレッチではありません。

うまくいけば、それは問題の事柄をすべて一度に決定します。

NotSupportedExpcetionを使用してください。

カスタムメイドの例外のスローは、疑わしい場合は常に行う必要があります。APIユーザーのニーズに関係なく、カスタム例外は常に機能します。開発者が気にしない場合は、どちらの例外タイプもキャッチできますが、開発者が特別な処理を必要とする場合は、SOLになります。

NotSupportedExceptionから継承するのはどうですか。@Mehrdadが最も理にかなっていることに同意しますが、完全に適合していないように見えるというあなたの意見を聞いています。そのため、NotSupportedExceptionを継承します。そのようにして、APIをコーディングする人々は、NotSupportedExceptionをキャッチできます。

私は常にカスタム例外を書くことに常に警戒しており、純粋にそれらが常に明確に文書化されているわけではないという理由で、正しく名前が付けられていないと混乱を引き起こします。

この場合、フラグチェックの失敗に対してArgumentExceptionをスローします。それは本当に好み次第です。私が見たいくつかのコーディング標準は、このようなシナリオでスローされる例外のタイプを定義することまで行っています。

ユーザーが列挙型ではない何かを渡そうとすると、InvalidOperationExceptionがスローされます。

編集：

他のものはこれがサポートされていないという興味深い点を提起します。NotSupportedExceptionに関する私の唯一の懸念は、「ダークマター」がシステムに導入されたときにスローされる例外、または言い換えると、「このメソッドはこのインターフェイスでシステムに入る必要がありますが、バージョン2.4になるまでオンにしないでください」

NotSupportedExceptionsがライセンス例外としてスローされることも確認しました。「このソフトウェアの無料バ​​ージョンを実行しているため、この機能はサポートされていません」。

編集2：

別の可能なもの：

System.ComponentModel.InvalidEnumArgumentException  

列挙子である無効な引数を使用するとスローされる例外。

InvalidOperationExceptionにも投票します。フレームワーク設計ガイドライン第2版に基づく.NET例外スローガイドラインで（不完全な）フローチャートを作成しました。しばらくの間、興味があれば戻ってきます。