Debug.Assertと例外のスロー

私は、アサーションの使用方法と使用時期に関する多くの記事（およびStackOverflowに投稿された他のいくつかの同様の質問）を読みましたが、それらをよく理解しています。しかし、それでも、Debug.Assert単純な例外をスローする代わりに、どのような動機で私を駆り立てるのか理解できません。つまり、.NETでは、失敗したアサーションに対するデフォルトの応答は、「世界を停止」してユーザーにメッセージボックスを表示することです。この種の動作は変更できる可能性がありますが、それを行うのは非常に煩わしく冗長であると思いますが、代わりに適切な例外をスローすることもできます。このようにして、例外をスローする直前にアプリケーションのログにエラーを簡単に書き込むことができ、さらに、アプリケーションが必ずしもフリーズするわけではありません。

それで、もしあるとすればDebug.Assert、明白な例外の代わりに使用する必要があるのはなぜですか？アサーションを本来あるべきではない場所に配置すると、あらゆる種類の「望ましくない動作」が発生する可能性があるため、私の見解では、例外をスローする代わりにアサーションを使用しても何も得られません。私に同意しますか、それともここで何か不足していますか？

注：「理論上」の違いは何なのか（デバッグとリリース、使用パターンなど）は完全に理解していますが、それを見ると、アサートを実行するのではなく、例外をスローした方がよいでしょう。プロダクションリリースでバグが発見された場合でも、「アサーション」を失敗させたいので（結局のところ、「オーバーヘッド」は途方もなく小さいので）、代わりに例外をスローした方がよいでしょう。

編集：私がそれを見る方法、アサートが失敗した場合、それはアプリケーションが何らかの破損した予期しない状態に入ったことを意味します。では、なぜ実行を続けたいのでしょうか？アプリケーションがデバッグバージョンとリリースバージョンのどちらで実行されているかは関係ありません。同じことが両方に行きます

私はあなたの推論がもっともらしいことに同意します-つまり、アサーションが予期せず違反された場合、スローすることによって実行を停止することは理にかなっています-私は個人的にアサーションの代わりに例外を使用しません。理由は次のとおりです。

他の人が言ったように、アサーションは不可能な状況を文書化する必要があります。つまり、不可能なとされる状況が発生した場合に、開発者に通知します。対照的に、例外は、例外的な状況、起こりそうもない状況、または誤った状況に制御フローメカニズムを提供しますが、不可能ではありません。私にとって、主な違いはこれです：

• 常に、指定されたthrowステートメントを実行するテストケースを作成できるようにする必要があります。このようなテストケースを作成できない場合は、プログラム内に実行されないコードパスがあり、デッドコードとして削除する必要があります。

• アサーションを起動させるテストケースを生成することは決して不可能であるべきです。アサーションが発生した場合、コードが間違っているか、アサーションが間違っています。いずれにしても、コードで何かを変更する必要があります。

そのため、アサーションを例外に置き換えません。アサーションを実際に起動できない場合は、アサーションを例外で置き換えることは、プログラムにテスト不可能なコードパスがあることを意味します。テストできないコードパスが嫌いです。

アサーションは、プログラマーの世界に対する理解をチェックするために使用されます。アサーションは、プログラマが何か間違ったことをした場合にのみ失敗するはずです。たとえば、アサーションを使用してユーザー入力をチェックしないでください。

「起こり得ない」条件のテストをアサートします。例外は、「発生してはならないが発生する」条件です。

アサーションは、ビルド時（または実行時）にその動作を変更できるので便利です。たとえば、多くの場合、リリースビルドでは、アサートは不要なオーバーヘッドが発生するためチェックされません。これも注意すべき点です。テストが実行されない可能性もあります。

アサートの代わりに例外を使用すると、いくつかの値が失われます。

1. 例外のテストとスローは少なくとも2行ですが、アサートは1行だけなので、コードはより冗長です。

2. テストとスローコードは常に実行されますが、アサートはコンパイルして取り除くことができます。

3. アサートはチェックとスローを行う製品コードとは異なる意味を持つため、他の開発者との通信が一部失われます。実際にプログラミングアサーションをテストする場合は、アサートを使用します。

詳細：http : //nedbatchelder.com/text/assert.html

編集： 投稿で行った編集/メモへの応答：達成しようとしていることの種類に対してアサーションを使用するよりも、例外を使用するのが正しいようです。あなたがたがう精神的な障害は、同じ目的を果たすために例外と主張を検討しているので、どちらが「正しい」のかを理解しようとしていることだと思います。アサーションと例外を使用する方法にはいくつかの重複があるかもしれませんが、それらが同じ問題に対する異なるソリューションであることを混同しないでください-そうではありません。アサーションと例外にはそれぞれ独自の目的、長所、短所があります。

私は自分の言葉で答えをタイプするつもりでしたが、これは私が持っているよりもこの概念をより正確にしています：

C＃ステーション：アサーション

assertステートメントの使用は、実行時にプログラムロジックエラーをキャッチする効果的な方法ですが、プロダクションコードから簡単に除外できます。開発が完了すると、コンパイル中にプリプロセッサシンボルNDEBUG [すべてのアサーションを無効にする]を定義するだけで、コーディングエラーに対するこれらの冗長テストの実行時コストを排除できます。ただし、アサート自体に配置されたコードは製品版では省略されることを忘れないでください。

アサーションは、次のすべてが成立する場合にのみ条件をテストするために使用するのが最適です。

* the condition should never be false if the code is correct,
* the condition is not so trivial so as to obviously be always true, and
* the condition is in some sense internal to a body of software.

ソフトウェアの通常の操作中に発生する状況を検出するためにアサーションを使用することはほとんどありません。 たとえば、通常、アサーションはユーザー入力のエラーをチェックするために使用されるべきではありません。ただし、アサーションを使用して、呼び出し元がユーザーの入力を既にチェックしたことを確認することは意味があります。

基本的に、本番アプリケーションでキャッチ/処理する必要があるものには例外を使用し、アサーションを使用して、開発には役立つが本番環境ではオフになっている論理チェックを実行します。

（考案された）実用的な例が違いを明らかにするのに役立つと思います：

（MoreLinqのBatch拡張機能から変更）

// 'public facing' method
public int DoSomething(List<string> stuff, object doohickey, int limit) {

    // validate user input and report problems externally with exceptions

    if(stuff == null) throw new ArgumentNullException("stuff");
    if(doohickey == null) throw new ArgumentNullException("doohickey");
    if(limit <= 0) throw new ArgumentOutOfRangeException("limit", limit, "Should be > 0");

    return DoSomethingImpl(stuff, doohickey, limit);
}

// 'developer only' method
private static int DoSomethingImpl(List<string> stuff, object doohickey, int limit) {

    // validate input that should only come from other programming methods
    // which we have control over (e.g. we already validated user input in
    // the calling method above), so anything using this method shouldn't
    // need to report problems externally, and compilation mode can remove
    // this "unnecessary" check from production

    Debug.Assert(stuff != null);
    Debug.Assert(doohickey != null);
    Debug.Assert(limit > 0);

    /* now do the actual work... */
}

したがって、Eric Lippertらが言ったように、あなた（開発者）が誤って別の場所で間違って使用した場合に備えて、正しいと思われるものだけをアサートするので、コードを修正できます。基本的に、たとえばユーザー入力の場合など、制御できない、または予期できない場合に例外をスローします。これにより、不良データを与えたもの（ユーザーなど）が適切に応答できるようになります。

Code Completeのもう1つのナゲット：

「アサーションは、仮定が真でない場合に大声で不平を言う関数またはマクロです。アサーションを使用して、コードで行われた仮定を文書化し、予期しない条件を洗い流します。...

「開発中、アサーションは矛盾する仮定、予期しない条件、ルーチンに渡される不正な値などを洗い流します。」

彼はさらに何を主張すべきか、何を主張すべきでないかについていくつかのガイドラインを追加します。

一方、例外：

「例外処理を使用して、予期しないケースに注意を引きます。例外的なケースは、開発中に明らかになり、本番用コードの実行中に回復できるように処理する必要があります。」

この本を持っていない場合は、購入する必要があります。

Debug.Assertはデフォルトではデバッグビルドでのみ機能するため、リリースビルドで何らかの予期しない悪い動作をキャッチする場合は、例外を使用するか、プロジェクトプロパティでデバッグ定数をオンにする必要があります（これは一般的には良い考えではありません）。

もののために使用アサーションARE可能ですが、起こるべきではありません（それは不可能だった場合は、アサーションを置く理由は、？）。

それを使用する場合のように聞こえませんExceptionか？なぜアサーションを使用するのExceptionですか？

なぜなら、アサーションのパラメーターがfalseになるのを止めるアサーションの前に呼び出されるコードがあるはずだからです。

通常Exception、スローされないことを保証するコードは、その前にありません。

製品にDebug.Assert()まとめられているのはなぜ良いのですか？デバッグでそれについて知りたい場合は、製品でそれについて知りたくないですか？

開発中にのみ必要です。Debug.Assert(false)状況を見つけたら、それがDebug.Assert(false)再び発生しないことを保証するコードを記述します。開発が完了したら、Debug.Assert(false)状況を見つけて修正したと仮定するDebug.Assert()と、は冗長になるため、安全にコンパイルできます。

あなたがかなり大規模なチームのメンバーであり、クラスでのオーバーラップを含め、同じ一般的なコードベースで作業している人が何人かいるとします。他のいくつかのメソッドによって呼び出されるメソッドを作成し、ロックの競合を回避するために、個別のロックを追加するのではなく、特定のロックを使用して呼び出しメソッドによって以前にロックされていたと想定します。たとえば、Debug.Assert（RepositoryLock.IsReadLockHeld || RepositoryLock.IsWriteLockHeld）; 他の開発者は、呼び出し側メソッドがロックを使用する必要があるというコメントを見落とす可能性がありますが、これは無視できません。