問題タブ [assert]

comp.lang.c++.moderated で、C++ ではデフォルトでデバッグ ビルドにのみ存在するアサーションを製品コードに保持する必要があるかどうかについての議論が進行中です。

明らかに、各プロジェクトは一意であるため、ここでの私の質問は、アサーションを保持する必要があるかどうかではなく、どの場合にこれが推奨されるか、または良い考えではないかということです。

主張とは、つまり：

• false の場合、ソフトウェアのバグを明らかにする条件をテストする実行時チェック。
• プログラムを停止するメカニズム (おそらく、最小限のクリーンアップ作業の後)。

必ずしも C や C++ について話しているわけではありません。

私自身の意見では、あなたがプログラマーであるが、データを所有していない場合 (ほとんどの商用デスクトップ アプリケーションがそうです)、アサーションの失敗はバグを示しているため、データを保持する必要があります。バグがあり、ユーザーのデータが破損するリスクがあります。これにより、出荷前に強力なテストを行う必要があり、バグがより目立ち、発見と修正が容易になります。

あなたの意見/経験は何ですか?

乾杯、

カール

関連する質問はこちら

応答と更新

グラハムさん、

アサーションはエラーであり、純粋で単純であるため、アサーションのように処理する必要があります。エラーはリリース モードで処理する必要があるため、実際にはアサーションは必要ありません。

そのため、アサーションについて話すときは「バグ」という言葉を好みます。それは物事をより明確にします。私にとって、「エラー」という言葉は漠然としすぎています。見つからないファイルはバグではなくエラーであり、プログラムで対処する必要があります。null ポインターを逆参照しようとするのはバグであり、プログラムは何か悪いチーズのようなにおいがすることを認識する必要があります。

したがって、ポインターはアサーションでテストする必要がありますが、ファイルの存在は通常のエラー処理コードでテストする必要があります。

少し話が逸れますが、議論の重要なポイントです。

注意点として、アサーションが失敗したときにアサーションがデバッガーに割り込む場合は、そうではありません。しかし、コードの完全な制御外にあるファイルが存在できない理由はたくさんあります: 読み取り/書き込み権限、ディスクがいっぱい、USB デバイスが取り外されているなど。制御できないため、アサーションはそれに対処する正しい方法ではありません。

カール

トーマス、

はい、私は Code Complete を持っていますが、その特定のアドバイスには強く反対します。

カスタム メモリ アロケータが台無しになり、他のオブジェクトがまだ使用しているメモリのチャンクをゼロにしたとします。このオブジェクトが定期的に逆参照するポインターをたまたまゼロにします。不変条件の 1 つは、このポインターが決して null にならないことです。その状態を維持するためのいくつかのアサーションがあります。ポインタが突然 null になったらどうしますか。それが機能することを期待して、それを if() するだけですか？

ここでは製品コードについて話しているので、デバッガーに侵入してローカル状態を検査する必要はありません。これは、ユーザーのマシンの実際のバグです。

カール

私は優れたクリーンコードを読んでいる最中です

1 つの議論は、null をメソッドに渡すことに関するものです。

これは、これを処理するさまざまな方法を表しています。

私はアサーションアプローチを好みますが、アサーションがデフォルトでオフになっているという事実は好きではありません。

この本は最後に次のように述べています。

ほとんどのプログラミング言語では、呼び出し元から誤って渡された null を処理する適切な方法はありません。これが事実であるため、合理的なアプローチは、デフォルトで null を渡すことを禁止することです。

この制限をどのように強制するかについては、実際には入りませんか?

どちらにしても、強い意見を持っている人はいますか。

を使用assert()してアサーションが失敗すると、assert()が呼び出さabort()れ、実行中のプログラムが突然終了します。私の製品コードではそれを行う余裕はありません。実行時にアサートする方法はありますが、失敗したアサーションをキャッチして、それらを適切に処理する機会がありますか?

John Robbins による「Debugging MS .Net 2.0 Applications」をざっと読み始めたところですが、彼の Debug.Assert(...) の伝道に混乱しています。

彼は、適切に実装された Assert は、エラー状態の状態をある程度格納することを指摘しています。たとえば、次のようになります。

さて、個人的には、彼が実際の賢明な「ビジネス ロジック」のコメントなしでテストを言い直すのが大好きなのがおかしいように思えます。

だから、私はAssertsを一種の低レベルの「私の仮定を守ろう」のようなものとして得ていると思います...これがデバッグでのみ行う必要があるテストであると感じていると仮定します-つまり、同僚から自分自身を保護していますそして将来のプログラマー、そして彼らが実際に物事をテストすることを望んでいます。

しかし、私が理解できないのは、彼は続けて、通常のエラー処理に加えてアサーションを使用する必要があると言っているということです。今、私が想定しているのは次のようなものです：

エラー条件テストの Debug.Assert の繰り返しによって何が得られましたか? 非常に重要な計算のデバッグのみのダブルチェックについて話しているなら、私はそれを理解できると思います...

...しかし、(DEBUGビルドとリリースビルドの両方で)確かにチェックする価値があるパラメーターテストでは取得できません...またはそうではありません。私は何が欠けていますか？

私はGCCコンパイラでLinuxに取り組んでいます。C ++プログラムがクラッシュしたときに、スタックトレースを自動的に生成したいと思います。

私のプログラムは多くの異なるユーザーによって実行されており、Linux、Windows、Macintoshでも実行されます（すべてのバージョンはを使用してコンパイルされますgcc）。

プログラムがクラッシュしたときにスタックトレースを生成できるようにしたいのですが、次にユーザーがそれを実行すると、問題を追跡できるようにスタックトレースを送信してもよいかどうかを尋ねられます。情報の送信は処理できますが、トレース文字列を生成する方法がわかりません。何か案は？

Visual Studio を使用してネイティブ アプリケーションを開発しています。コードに __asm int 3 または __debugbreak を使用して配置されたプログラム ブレークポイント (アサート) があります。ヒットしたときに、同じデバッグセッションでの連続したヒットがデバッガーに侵入しないように、それを無効にしたい場合があります。これどうやってするの？

契約によってプログラミングする場合、関数またはメソッドは、その責任に取り組み始める前に、その前提条件が満たされているかどうかを最初にチェックしますよね? これらのチェックを行う最も顕著な 2 つの方法は、 byassertと byexceptionです。

1. assert はデバッグ モードでのみ失敗します。個別のコントラクトのすべての前提条件を (ユニット) テストして、実際に失敗するかどうかを確認することが重要であることを確認します。
2. 例外は、デバッグおよびリリース モードで失敗します。これには、テスト済みのデバッグ動作がリリース動作と同じであるという利点がありますが、実行時のパフォーマンスが低下します。

どちらが好ましいと思いますか？

ここで関連する質問を参照してください

時折、何もアサートしない単体テストに出くわします。私が今朝遭遇した特定の例は、条件が満たされたときにログ ファイルが書き込まれることをテストすることでした。エラーがスローされなければ、テストは成功したと想定されていました。

私は個人的にこれに問題はありませんが、アサーションが関連付けられていない単体テストを作成するのは少し「コードの匂い」のようです。

これについて人々の意見がどうなっているのか疑問に思っていますか？

Kent Beck の xUnit に相当するものを Ruby でコーディングすることで、Ruby の理解を深めています。Python (Kent が書いている) には、広く使用されている言語の assert() メソッドがあります。Ruby はそうではありません。これを追加するのは簡単だと思いますが、カーネルはそれを置くのに適切な場所ですか?

ところで、私は Ruby にさまざまな Unit フレームワークが存在することを知っています。これは、「何かを成し遂げる」ためではなく、Ruby のイディオムを学ぶための演習です。

一部のコードが例外をスローすることをテストするために慣用的に JUnit4 を使用するにはどうすればよいですか?

私は確かにこのようなことをすることができますが：

この種の状況では、アノテーションやAssert.xyz など、はるかにぎこちなく、はるかに JUnit の精神に則ったものがあることを思い出します。