設計に関する FAQ - AssertionError クラス

1. Expression₂ が存在しない assert 文によって AssertionError が生成される場合、表明された状態のプログラムテキストが詳細なメッセージとして使用されない (たとえば、「height < maxHeight」) のはなぜでしょうか。

   こうすることによって、アサーションの「既成概念にとらわれない」便利さを向上させる場合もありますが、このような文字列定数すべてを .class ファイルと実行時イメージに追加するということで発生するコストに見合うほどの利点ではありません。

2. AssertionError が発生すると、このエラーを生成したオブジェクトにアクセスできなくなるのはなぜでしょうか。同様に、詳細なメッセージの代わりに、任意のオブジェクトをアサーションから AssertionError に渡さないのはなぜでしょうか。

   このようなオブジェクトへのアクセスを許可すると、プログラマがアサーションの失敗からの復帰を試みようとするため、アサーション機能の目的から逸脱します。

3. コンテキストアクセス用メソッド (getFile、getLine、getMethod など) を AssertionError で提供しないのはなぜでしょうか。

   この機能は Throwable で提供するのが最良であるので、AssertionError だけではなく、すべての Throwable で使用できます。アサーション機能が最初に登場するリリースまでには、Throwable を拡張して、この機能を提供できるようにする予定です。

4. AssertionError が RuntimeException ではなく Error のサブクラスなのはなぜでしょうか。

   この問題は大いに議論されました。専門家グループが長時間議論した結果、プログラマがアサーションの失敗を復帰しないようにするには、Error がより適切であるという結論に達しました。一般的には、アサーションが失敗した原因を突き止めることは困難または不可能です。このような失敗は、プログラムが「未知の領域」で動作しており、実行を継続しようとすると危険であることを示しています。さらに、規約によると、メソッドはスローする可能性があるほとんどのランタイム例外を (「@throws」doc コメントにより) 指定することになっています。アサーションの失敗を生成するような条件をメソッドで指定するのは意味がありません。このような情報は実装の詳細である (つまり、実装やリリースごとに変更できる) と考えることができます。