assertキーワードはJava 1.4で登場しました。 多くの人はまだそれを避けようとしている、またはユーティリティの静的メソッドにラップして、
assert condition : message;をすばやく変更できるようにしてい
assert condition : message; に
if (!condition) throw new AssertionError(message);
コード全体。 誰かがチェックの信頼性が十分でないことを恐れており、誰かがそれをオンにするのを忘れると、いくつかのバグが気付かれなくなります。 反対に、誰かがパフォーマンスについてマニカルに考えます：誰かが最初のグループの人によって書かれたサブシステム/ライブラリのチェックをオンにし、「生産的な」ライブラリのパッケージまたはクラスを
除外するのを忘れると、無駄な計算によって実行が遅くなります。
私の意見では、チェックには何も問題はありませんが、コード上で可能な限り寛大に配置することができます。 まず、すでに述べたように（ただし、これは新しい可能性があります）、JVMの起動時とプログラム（ClassLoaderを
使用 ）の両方で、チェックを柔軟に構成できます（
パッケージおよび個々のクラスで有効化/無効化 ）。したがって、あるシステムでチェックを突然オンにし、別のシステムでオフにしたい場合、これは間違いなく解決すべき問題です。
第二に、時々、
- == false trueような些細な条件ではなく、クラス内の
チェック状態を維持し、メソッドでチェックしたいことがあります。
assertトリックを使用すると、チェックを無効にして実行すると、ほぼ無料でこれを実現できます。
トリックは簡単です：検証状態の初期化と更新は、意味によって何も返さないメソッド（
void ）、およびコード内で行われます-
booleanで常に
trueです。 これらのメソッドは、「スルー」
assertと呼ばれます。 つまり、クラスのチェックが無効になっている場合、メソッドは呼び出されず、テスト状態は初期化または更新されず、オーバーヘッド内のオブジェクトメモリには
null参照が1つだけ残ります。
例：
import java.util.HashSet; import java.util.Set; public final class MyCoolSet<E> { private Object[] coolStorage; private transient Set<E> referenceSet; public MyCoolSet() {