これは実際には「質問」ではないので、CW にしています。
の
assert
キーワードがスゴイ！
書いたコードに自信が持てるようになるはずですが、今日まで、小さなテストクラス (< 20 行) を作成していたときまで、導入されて以来、決して使用しないことに気付きました。
なんてこった！確かに非常に便利なロガーはほとんど使用していませんが、アサーションを使用していないことに今日まで気づきませんでした。
アサーションを使用しますか？いいえの場合、その理由は何ですか?
2952 次
16 に答える
14
私は 90 年代に多くのアサーションを使用するように教えられましたが、それらは非常に理にかなっています。それは良い防御コーディングです。
しかし、これは現在、実際にコードを強制的に実行し、どこが壊れているかを示す単体テストに取って代わられていると思います。デバッグ アサートでは、誰かが実際にデバッグ コードを実行し、UI またはログを確認する必要がありました。単体テストはこれを自動化できます。
于 2009-07-30T18:31:05.277 に答える
14
私はいつもそれらを使用しています。これらは、「早期にクラッシュする」という哲学を実践するための良い方法であり、アサーションが失敗した理由を解決する方が、悪い/破損した出力に対処するよりも優れています。
問題は、それを習慣化する必要があるということです。私はめったに妥協点を見ません。人々はそれに慣れておらず、ほとんど使用していないか、人々がそれらを使用していてコード全体に散らばっています。「ああ、ここで暗黙のうちに何かを仮定しているので、明示的に「assert(ASSUMPTION)」と確認させてください」という考え方に入る必要があります。
于 2009-07-30T18:33:42.180 に答える
11
コードにエラーが発生しないように、アサーションを使用します。値がマップに含まれるべきであることがわかっている場合は、そのためにアサートします（assertキーワードを使用）。パラメータがnullであってはならないことがわかっている場合は、それを主張します。パラメータがnullになる可能性があることがわかっている場合は、それをチェックして適切な例外をスローします。
私はCodeCompleteまたはEffectiveJavaでそれを読みました-プログラミングエラーを検出するためにアサーションを使用する必要があります-例外的である可能性のある状況を処理するために例外を使用する必要があります。値が（コントラクトで定義されているように）nullにならないことがわかっている場合は、コードのすべてのメソッドでnullをチェックする必要はありませんが、値がnullでない場合でもアサートしても問題ありません。アサーションは、VMにパラメーター-eaを指定した場合にのみ有効になり、無効にした場合でもアプリケーションのパフォーマンスに影響を与えることはありません。
あなたもより多くのロギングを使用する必要があります:-)。トレース、デバッグ、および情報をいつ使用するかを学び、アプリケーションが実行するすべてのことをログに記録するようにしてください。実稼働環境で何かが機能していない理由を理解する必要がある場合、これにより作業が非常に簡単になります。
于 2009-07-30T19:36:37.373 に答える
4
単体テストが導入された後のアサーションの唯一の実際の使用法は、メソッドの不変条件を他のプログラマーに伝えることです。そして、とにかく無視するコメントよりも、実際のコードでこれを行う方がはるかに優れています。アサートを無視するのは難しいです！
于 2009-07-30T21:11:35.747 に答える
4
簡単な答え - はい。
長い答え - 常にではありませんが、非常に頻繁です。私は通常、（プログラムの実行中に）何もできないことがわかっているエラーに対してアサーションを使用し、ログは実際には必要ありません。例-特定の値が範囲外であるかどうか、またはポインターに値があるはずなのにNULLであるかどうかを確認する必要がある場合。
「ファイルの解析中」や「ファイルが見つかりませんでした」などの他のものについては、通常、例外をスローします。そうすれば、エラーをログに記録し、代わりにフェイル セーフ ファイル/メソッドを使用できます。
そして、私はファライナに非常に同意します。あなたは本当に注意する必要があります-「ねえ、私はここでいくつかの仮定を行っています」
于 2009-07-30T18:42:09.323 に答える
3
私はそれらを使用しません。コードをテストするには単体テストで十分です。さらに、これらはデフォルトで無効になっているため、通常は完全に無視されます。次に、コメントとしてより適切に表現できる無用なアサーションでコードを乱雑にする傾向があります。
ただし、これが本当に必要な場合は、一部のライブラリには、スキップされずに呼び出すことができるアサーション静的メソッドがあります。これらは、 assert キーワードが一般的ではなく、すぐに「wtf」の瞬間を引き起こす可能性があるため、はるかに読みやすくなっていますが、Assert .x メソッドは、トレースできるメソッドにすぎません。特に、Spring フレームワークはアサーション ライブラリを使用します。
于 2009-07-30T18:40:06.723 に答える
2
はい！いつも！キーワードは、すべての言語での私の親友です!
アサートを使用しない本当の理由はありません。アサートは、入力値と状態に対して行う基本的な仮定が確実に守られるようにします。
アサートが失敗した場合は、仮定を再評価し、コードを更新して、現在のリビジョンを作成するときに考えもしなかった新しいエキゾチックな入力を処理する必要があることを意味します。それについて何が気に入らないのですか？
プログラミングではよくあることですが、適切に使用して初めて強力になるツールです。
于 2009-07-31T14:11:47.617 に答える
2
アサートが好きなら、コントラクトも気に入るはずです。それらは基本的に、より多くの状況に拡張されたアサートのアイデアです。
于 2009-07-30T23:21:12.630 に答える
2
いいえ、絶対に使用しないでください。理由はわかりませんが、習慣になりませんでした。
于 2009-07-30T18:26:23.927 に答える
2
はい、私は常に assert を使用しています。
- かなり単純な述語で確認できます。
- 近くのコードを読むだけでは明らかに真実ではありません。
ただし、パフォーマンスにほとんど影響を与えない可能性が高い assert については、enforce代わりに D プログラミング言語標準ライブラリの関数を使用しますassert。assertこれは、リリース モードのままであることを除いて、基本的には と同じことを行います。より高価なアサーションについてassertは、リリース モード ビルドから削除された を使用します。
于 2010-02-15T01:05:48.790 に答える
1
Javaのassertキーワードはかなり半分評価されているので（-eaコマンドラインオプションを指定してプログラムを実行する必要があります）、assertではなく例外に依存していることに気付きます。
于 2009-07-30T19:57:24.557 に答える
1
私はエラー状態をチェックし、代わりに例外をスローする傾向があります。その理由は、本番環境であっても、これらの条件を常にチェックする必要があり、例外を使用すると、アサーションよりも失敗した条件を簡単に処理できるからです。
于 2009-07-30T18:42:37.700 に答える
0
いいえ、使いません。
私はアサートを「プロダクション」コードで使用すべきではないと教えられました。とにかく削除する必要があるものを使用する前に、私が学んだことによると、条件を検証することを例外として固執します。
于 2009-07-30T19:46:07.713 に答える
0
私はそれらを使用したことはありませんでしたが、最後のプログラムをデバッグするのにひどい時間を過ごしました。ある時点で、変数がnullであるか、期待する値が含まれていないときにログを記録していました。すべてが機能するようになったら、プログラムを正常に実行するために必要なすべてをアサートしました。
于 2009-07-30T19:54:08.197 に答える
0
理由はわかりませんが、私はそれらを使用しない傾向があります。
nUnit などで単体テストを行う場合、テスト結果を検証するためにそれらを常に使用することは明らかです。
于 2009-07-30T18:28:03.457 に答える
0
いいえ、でも待ちきれません。以前は junit を使用してすべてのユニット テストを行っていましたが、それは学校であり、小さなプロジェクトではプレッシャーはありませんでした。私は今実生活にいます。昨日このコードを完成させるはずでした....
于 2009-07-30T23:15:59.443 に答える