「安定」し、テストおよび本番環境に移行されたコードにTrace.Assert
andステートメントを残すことは賢明ですか?Debug.Assert
もしそうなら、これらのアサーションステートメントはどのように役立ちますか? Guard クラスなどで例外条件をチェックし、必要に応じて例外を発生させるだけで十分ではないでしょうか。
Debug.Assertステートメントは、DEBUG コンパイル定数が定義されていない限り無視されます。これは、デフォルトでは、「リリース」構成ではなく「デバッグ」構成でコンパイルするときに発生します。実際、Debug クラスは、Debug.Assert が失敗する原因となるバグのすべて (または少なくともほとんど) をキャッチする必要があるテスト環境でのみ使用することを意図しています。
Trace.Assertは、存在しなければならないコンパイル定数が TRACE であることを除いて、同じように機能します。TRACE は、デフォルトで「デバッグ」構成と「リリース」構成の両方に存在します。リリース コードにトレース アサーションを含めることは理にかなっているかもしれませんが、通常は、メソッドの既定の動作 (スタック トレースと共にメッセージ ボックスを表示するだけ) 以外のことを行うようにすることが望ましいです。これは、Trace クラスのカスタム トレース リスナーを構成することで実現できます。詳細については、メソッドのドキュメントを参照してください。
Prod 環境への移行は始まりであり、プログラムの寿命の終わりではありません。実際のユーザーや現実の世界に出会うと、予期していなかった問題やニーズについて多くのフィードバックが得られるようになります。つまり、開発は始まったばかりです。誤った仮定を早期に (それらが多くの問題を引き起こす前に) 見つけ出し、プログラムを拡張および変更するのに役立つように、アサートを配置する必要があります。
例外に対するアサートの利点の 1 つは、問題が発生した場所で例外をキャッチしない可能性があることです。しかし、Assert は常に適切な場所で発生します。
私が考えることができる Assert のもう 1 つの利点は、運用環境でのデバッグに役立つことです。リリース コードでまだアクティブなアサーションは、 DbgViewなどの適切なツールを使用して実行時に動的にキャプチャできます。これは、製品がリリースされた後のデバッグに非常に便利です。
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx