Java ではAssertionError、特定の行に到達しないことをアサートするために、直接 をスローすることがあります。この例はdefault、ステートメントのケースにswitch到達できないことをアサートすることです (例については、この JavaSpecialists ページを参照してください)。
.Net でも同様のメカニズムを使用したいと考えています。使用できる同等の例外はありますか? または、同じ効果で使用できる別の方法はありますか?
編集- 明確にするために、リリースされたコードで実行時にエラーにフラグを立てて、コード内の不変式の（おそらく壊滅的な）エラーが発生したことを示すメカニズムを探しています。リンクされた例では、0 から 2 (両端を含む) の間のランダムな整数を生成し、生成された数値が常に 0、1、または 2 であることを主張しています。システムの破損状態。
私は通常、値がどこから来たのかに応じて、InvalidOperationExceptionまたはスローします。ArgumentOutOfRangeException
または、 (DEBUG プリプロセッサ シンボルが定義されている場合にのみ失敗します) または .NET 4.0 では、または状況に応じてDebug.Assert使用できます。ただし、明示的に例外をスローすると、次のステートメントに到達できないことをコンパイラーが認識できるという利点があります。Contract.FailContract.AssertContract.Assume
私は大ファンではありませんDebug.Assert-通常、リリースには不適切です（単に失敗するのではなく、アサーションボックスをスローするため）、とにかくリリースではトリガーされません。「何かが間違っている」ことを検出する機会があった後でも、コードが実行されないようにするため、常にスローされる例外を好みます。
Code Contracts は、実行時に保存されるものにはあらゆる種類のオプションがあり、静的チェッカーは、その状態にならないことを証明するのに役立つため、ゲームを多少変更します。ただし、実行時間ポリシーを選択する必要があります...
Trace.Assertリリース ビルドで機能するメソッドを使用できます( TRACEVisual Studio プロジェクトで既定で定義されているコンパイル シンボルが定義されている場合)。アプリケーションがアサーション エラーに反応する方法をカスタマイズすることもできますTraceListener。デフォルトは (当然のことながら) でDefaultTraceListener、アプリケーションが対話モードで実行されている場合、ダイアログ ボックスにアサーションが表示されます。たとえば、例外をスローする場合は、独自の例外を作成TraceListenerしてメソッドでスローできますFail。その後、プログラムまたは構成ファイルでを削除してDefaultTraceListener、独自のものを使用できます。
これは大変な問題のように見えますが、アプリケーションがトレース リスナーを介してアサーションを処理する方法を動的に変更したい場合にのみ正当化されます。常に失敗させたい違反については、独自のAssertionExceptionクラスを作成してすぐにスローします。
.NET 4.0の場合、私は間違いなくContract.Assertメソッドを調べます。ただし、このメソッドはシンボルDEBUGまたはCONTRACTS_FULLが定義されている場合にのみコンパイルされます。DEBUGリリース ビルドでは機能せず、CONTRACTS_FULL他のすべてのコントラクト チェックもオンになります。その一部は、リリース ビルドに存在したくない場合があります。