アサーションを製品コードに残しておくべきなのはいつですか? [closed] 質問する

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

もちろん、それぞれのプロジェクトはユニークです。そこで私の質問はないそんなにかどうか主張は守られるべきである、しかし、どのような場合にこれは推奨される/良い考えではない。

主張とは、次のことを意味します。

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

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

私の意見としては、プログラマーであってもデータを所有していない場合 (ほとんどの商用デスクトップ アプリケーションがこれに該当)、アサーションを有効にしたままにしておくべきです。アサーションが失敗するとバグが示され、バグがある状態で続行するとユーザーのデータが破損するリスクがあるためです。これにより、出荷前に厳重にテストする必要があり、バグが目立ちやすくなるため、バグを見つけて修正しやすくなります。

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

関連する質問を見るここ

回答と更新

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

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

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

少し話題から外れますが、議論の中では重要なポイントです。

念のため言っておきますが、アサーションが失敗したときにデバッガーに侵入するのであれば、それは構いません。しかし、読み取り/書き込み権限、ディスクがいっぱい、USB デバイスが取り外されているなど、コードで完全に制御できない理由でファイルが存在できないケースはたくさんあります。制御できないので、アサーションはそれに対処する適切な方法ではないと思います。

はい、私は Code Complete を持っていますが、その特定のアドバイスには強く反対だと言わざるを得ません。

たとえば、カスタム メモリ アロケータが失敗し、他のオブジェクトによってまだ使用されているメモリ チャンクをゼロに設定した場合を考えます。このオブジェクトが定期的に逆参照するポインタをたまたまゼロに設定し、不変条件の 1 つはこのポインタが null にならないことであり、その状態を維持するようにアサーションをいくつか実行します。ポインタが突然 null になった場合はどうしますか。うまくいくことを期待して、if() で囲むだけですか?

覚えておいてください、ここでは製品コードについて話しているので、デバッガーに侵入してローカル状態を検査することはできません。これは、ユーザーのマシン上の実際のバグです。