最近、.Net Rocks show 570（ http://devjourney.com/community/dotnet-rocks-show-570-with-kevin-hazzard/ ）でのコードコントラクトに関するKevinHazzardの話を聞きました。彼は、実行時の契約チェックを有効にすることを、一部の人が使用することを選択する可能性がある一方で、他の人は使用しない可能性があるオプションとして言及しています。
コードコントラクトにランタイムコントラクトチェックを使用しないのはなぜですか？パフォーマンスに重大な悪影響はありますか？その他の理由？
この機能を無効にした場合、実行時にメソッドの前提条件をどのように処理しますか？
一部のミッションクリティカルではないアプリケーションでは、ユーザーの前でエラーダイアログをスローするのではなく、実際にリリースビルドでエラーをスライドさせたい場合があります。エンドユーザーが気付かない可能性のある小さなバグにより、コントラクトチェックが失敗し、ユーザーエクスペリエンスが損なわれる可能性があります。
コントラクトと別の形式の前提条件チェックの両方を使用することは私には思えません。おそらく、前提条件を複製してしまうからです。
コントラクトチェックを使用すると、クライアントに.Net Framwork 4.0以降を強制することになります-パフォーマンスに関する限り、これが問題になるとは想像できませんが、一方通行で決定を下す前にテストするのが最善です。または別の。
コードコントラクトのドキュメントには、実行時にコードコントラクトを使用する方法に関するセクションがあります。実行時にコードコントラクトをどのように使用するかを事前に決定してから、ドキュメントのガイドラインに従って続行することをお勧めします。
リリースビルドでランタイムチェッカーを使用しない場合は、コードコントラクトの前提条件ではなく、レガシーの「if...thenthrow」前提条件を作成することをお勧めします。デバッグビルドに事後条件と不変条件を書き込むことはできますが、実行時にチェックされません。ただし、コードコントラクトを有効にしてデバッグする場合は、デバッグビルドで引き続き役立ちます。
多くの場合、例外から回復したい場合は、その原因に関する詳細が必要です。これには通常、独自の例外クラスを作成し、詳細をプロパティとして証明することが含まれます。最も基本的な例を使用するために、anArgumentOutOfRangeExceptionにはプロパティが含まれています。このプロパティActualValueを読み取って、取得した値に基づいて何をするかを決定できます。
コントラクトを使用する場合、コントラクトが失敗すると、ContractExceptionコンパイラによって生成されたベーシックが提供され、コントラクトの失敗に関する詳細のみが文字列形式で含まれます。これには、必要なものを抽出するために複雑な解析が必要になる場合があります。 -通常、わざわざそれを行うことはありません。
独自の例外を使用している場合は、実行時にコントラクトを保持する理由はありません。これは、コントラクトが失敗しようとしても到達しないためです。何も指示を無駄にするだけです。
独自の例外チェックと一緒に静的コントラクトチェックを使用することは、エラーを排除するための最も効果的な形式です。ほとんどの場合、アプリを実行する前に問題を修正する方法が指示されているため、例外がスローされることはありません。