アサーションはいつプロダクションコードに残すべきですか？[閉まっている]

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

明らかに、各プロジェクトは一意であるため、ここでの私の質問は、アサーションを保持する必要があるかどうかについてはそれほどではありませんが、その場合、これは推奨できる/良いアイデアではありません。

アサーションとは、次のことを意味します。

• falseの場合にソフトウェアのバグを明らかにする条件をテストするランタイムチェック。
• プログラムを停止するメカニズム（多分本当に最小限のクリーンアップ作業の後）。

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

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

あなたの意見や経験は何ですか？

乾杯、

カール

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

応答と更新

グラハムさん、

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

そのため、私は主張について話すときに「バグ」という言葉を好む。それは物事をより明確にします。私にとって、「エラー」という言葉は曖昧すぎます。欠落しているファイルはエラーではなくバグであり、プログラムはそれを処理する必要があります。nullポインタを逆参照しようとするのはバグであり、プログラムは何かが悪いチーズのようなにおいがすることを認めるべきです。

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

少し話題外ですが、議論の重要なポイントです。

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

カール

トーマス、

はい、私はコードコンプリートを持っています。その特定のアドバイスに強く同意しないと言わなければなりません。

カスタムメモリアロケータが失敗し、他のオブジェクトがまだ使用しているメモリのチャンクをゼロにするとします。私はたまたま、このオブジェクトが定期的に逆参照するポインターをゼロにします。不変条件の1つは、このポインターがnullになることはないということです。ポインタが突然nullになった場合はどうしますか。あなたはちょうどそれの周りにif（）、それがうまくいくことを望んでいますか？

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

カール

アサーションは、古くならないコメントです。それらは、どの理論状態が意図されているか、およびどの状態が発生してはならないかを文書化しています。コードが変更されて状態が変更を許可された場合、開発者はすぐに通知を受け、アサーションを更新する必要があります。

Steve McConnellのCode Completeを引用させてください。アサーションに関するセクションは8.2です。

通常、プロダクションコードでアサーションメッセージをユーザーに表示しないようにします。アサーションは、主に開発およびメンテナンス中に使用するためのものです。アサーションは通常、開発時にコードにコンパイルされ、本番用にコードからコンパイルされます。

ただし、同じセクションの後半で、このアドバイスが提供されます。

非常に堅牢なコードの場合は、とにかくアサートしてからエラーを処理します。

パフォーマンスが問題にならない限り、アサーションはそのままにして、メッセージを表示するのではなく、ログファイルに書き込むようにしてください。アドバイスもコードコンプリートにあると思いますが、今のところ見つかりません。

プログラムをオフにした方がプログラムの実行が大幅に速くなることが測定されていない限り、製品コードではアサーションをオンのままにします。

より効率的であることを証明するために測定する価値がない場合、パフォーマンスギャンブルのために明快さを犠牲にする価値はありません。」-Steve McConnell 1993

http://c2.com/cgi/wiki?ShipWithAssertionsOn

本番環境でアサーションを残すことを考えている場合でも、おそらくそれらを間違っていると考えているでしょう。アサーションの全体的なポイントは、それらがソリューションの一部ではないため、本番環境でオフにできることです。これらは開発ツールであり、想定が正しいことを確認するために使用されます。しかし、本番環境に移行するときは、すでに想定に自信があるはずです。

とはいえ、本番環境でアサーションをオンにするケースが1つあります。本番環境で再現可能なバグが発生し、テスト環境で再現できない場合は、アサーションをオンにしてバグを再現すると役立つ場合があります。本番環境で、有用な情報を提供しているかどうかを確認します。

より興味深い質問は次のとおりです。テスト段階で、いつアサーションをオフにしますか？

アサーションは製品コードに留まるべきではありません。特定のアサーションがプロダクションコードで役立つと思われる場合は、アサーションであってはなりません。これは、実行時エラーチェック、つまり次のようにコーディングされたものでなければなりませんif( condition != expected ) throw exception。

「アサーション」という用語は、「フィールドで実行されない開発時のみのチェック」を意味するようになりました。

アサーションがフィールドに到達する可能性があると考え始めると、必然的に、特定のアサーションが本当に作成する価値があるかどうか疑問に思うなど、他の危険な考えも開始します。作成する価値のない主張はありません。「これを断言すべきかどうか」と自問するべきではありません。「断言するのを忘れたものはありますか？」

アサーションがパフォーマンスの問題を引き起こしていることをプロファイリングが示していない限り、私はそれらも本番リリースにとどまるべきだと言います。

ただし、これには、アサーションの失敗をある程度優雅に処理することも必要だと思います。たとえば、プログラムを終了したりクラッシュさせたりするだけでなく、開発者に問題を（自動的に）レポートするオプションを備えた一般的なタイプのダイアログが表示されるはずです。また、実際に許可する条件にアサーションを使用しないように注意する必要がありますが、望ましくない、または望ましくないと考えてはいけません。これらの条件は、コードの他の部分で処理する必要があります。

私のC ++では、アサーションがリリースビルドで失敗した場合に例外をスローすることを除いて、assert（x）に似たREQUIRE（x）を定義しています。

アサーションの失敗はバグを示しているため、リリースビルドでも真剣に扱う必要があります。コードのパフォーマンスが重要な場合、高速で実行する必要がある高レベルのコードにはREQUIRE（）を使用し、低レベルのコードにはassert（）を使用することがよくあります。サードパーティが書き込んだコードから渡されたデータやファイルの破損が原因でエラー状態が発生する可能性がある場合は、アサートの代わりにREQUIREも使用します（最適な方法では、ファイルが破損した場合に適切に動作するようにコードを設計しますが、常にそうする時間はありません。）

彼らはあなたがそれらを理解しないのでそれらの断言メッセージをエンドユーザーに見せるべきではないと言います。そう？エンドユーザーは、スクリーンショットまたはエラーメッセージのテキストを含むメールを送信する場合があり、デバッグに役立ちます。ユーザーが単に「クラッシュした」と言っただけでは、修正する能力が低くなります。アサーションエラーメッセージをインターネット経由で自動的に自分に送信することをお勧めしますが、これは、ユーザーがインターネットにアクセスでき、許可を得ることができる場合にのみ機能します。

それらを保持したい場合は、エラー処理に置き換えます。プログラムが消えるだけで最悪です。特定のエラーを深刻なバグとして扱うことには何の問題もないと思いますが、データを収集してログに記録し、アプリに望ましくない状態が発生したことをユーザーに通知することで対処するように備えられているプログラムのセクションに転送する必要があります。終了します。

他のエラーと同様に処理されれば、問題は発生しません。他の言語と同様に、Cでの失敗したアサーションはプログラムを終了するだけであり、これは通常、実動システムでは不十分です。

いくつかの例外があります。たとえば、PHPではアサーションエラーのカスタムハンドラーを作成できるため、単に終了するだけでなく、カスタムエラーを表示したり、詳細なログを作成したりできます。

当社のデータベースサーバーソフトウェアには、本番アサーションとデバッグアサーションの両方が含まれています。デバッグアサーションはそれだけです。本番コードでは削除されています。本番アサーションは、（a）存在してはならない状態が存在し、（b）この状態から確実に回復できない場合にのみ発生します。製品のアサーションは、ソフトウェアのバグが発生したか、または何らかのデータ破損が発生したことを示しています。

これはデータベースシステムであり、エンタープライズクリティカルな可能性のあるデータを格納しているため、データの破損を防ぐためにできる限りのことを行います。不適切なデータを保存する可能性のある状態が存在する場合、すぐにすべてのトランザクションをアサートし、ロールバックして、サーバーを停止します。

そうは言っても、パフォーマンスが重要なルーチンでは本番アサーションを回避しようとします。

アサートをインラインユニットテストと見なします。開発中の迅速なテストに役立ちますが、最終的にはこれらのアサーションをリファクタリングして、ユニットテストで外部からテストする必要があります。

範囲内にあるすべてのエラーを処理し、アサーションを使用して、私たちがARE trueであると仮定していると仮定します。

つまり、プログラムがファイルを開いたり、読み込んだり、閉じたりしている場合、そのファイルを開くことができないことはスコープ内にあります-言い換えると、無視するのは怠慢なのです。したがって、エラーチェックコードが関連付けられているはずです。

ただし、fopen（）が常に有効なオープンファイルハンドルを返すと記載されているとします。ファイルを開き、それをreadfile（）関数に渡します。

このコンテキストでのreadfile関数は、おそらくその設計仕様によると、有効なファイルptrを取得するとほぼ想定できます。したがって、このような単純なプログラムで、否定的なケースのエラー処理コードを追加することは無駄です。ただし、実行を続行する前に、少なくとも仮定を文書化する必要があります。誤って呼び出された場合や、たとえば他のプログラムにコピー/貼り付けされた場合に備えて、が常に有効であると実際に想定するべきではありません。

したがって、readfile（）{assert（fptr！= NULL）; この場合は..}が適切ですが、本格的なエラー処理は適切ではありません（実際にファイルを読み取るには何らかのエラー処理システムが必要になるという事実を無視します）。

そして、はい、それらのアサーションは、それらを無効にすることが絶対に必要な場合を除いて、本番用コードに留まる必要があります。それでも、パフォーマンスが重要なセクション内でのみ無効にする必要があります。

コードの一部が本番環境にあり、通常はトリガーされるアサーションにヒットするとします。アサーションでバグが見つかりました！アサーションがオフになっているため、そうではありません。

それで今何が起こるのでしょうか？プログラムは、（1）問題の原因からさらに離れた時点で、情報を提供しない方法でクラッシュするか、（2）正常に完了まで実行され、おそらく間違った結果をもたらします。

どちらのシナリオも魅力的ではありません。本番環境でもアサーションをアクティブのままにします。

アサーションは、コンパイル時の型チェック以外のものにはほとんど使用しません。ほとんどの言語がそれらを処理するように構築されているからといって、アサーションの代わりに例外を使用します。

例を挙げます

file = create-some-file();
_throwExceptionIf( file.exists() == false, "FILE DOES NOT EXIST");

に対して

file = create-some-file();
ASSERT(file.exists());

アプリケーションはアサーションをどのように処理しますか？私try catchは、致命的なエラーを処理する古い方法を好みます。

ほとんどの場合、Javaでアサーション（assertキーワード）を使用すると、後でいくつかの製品コードが自動的に追加されます。場合によっては、ログメッセージ、例外、または何もありません。

私によると、すべてのアサーションは、製品リリースではなく開発リリースで重要です。それらのいくつかは保持する必要があり、他は破棄する必要があります。

アサーションはエラーではないため、エラーとして処理しないでください。アサーションがスローされた場合、これは、コードまたはコードを呼び出すコードにバグがあることを意味します。

本番コードでアサーションを有効にしないようにするためのポイントがいくつかあります。1.エンドユーザーに「ASSERTION failed MyPrivateClass.cpp line 147」のようなメッセージが表示されないようにします。エンドユーザーはQAエンジニアではありません。2。アサーションはパフォーマンスに影響を与える

ただし、アサーションを残すべき1つの大きな理由があります。ASSERTIONはパフォーマンスとタイミングに影響を与える可能性があり、悲しいことにこれが問題になる場合があります（特に組み込みシステムの場合）。

私はアサーションをプロダクションコードに残すことに投票する傾向がありますが、これらのアサーションの印刷出力がエンドユーザーに公開されないようにしてください。

〜Yitzik

アサーションはエラーであり、純粋で単純であるため、アサーションは同じように処理する必要があります。

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

アサーションについて私が見る主な利点は、条件付きの中断です。これらは、VCのウィンドウをドリルスルーして1行のコードで何かをセットアップするよりもはるかに簡単にセットアップできます。