3

JVM との単独戦闘に参加してから何年も経ちましたが、何かを忘れているようです。

大量のアサーションを含むいくつかのコードを取得しましたが、カスタム メッセージはありません。VMに渡されていることassert some_condition; を確認した単純な古いものであり、起動時にアサーションが有効になっていることをプログラムで再確認しました。-ea

コールチェーンの上昇は、次のようなコードです：

try {
    start_the_deeply_nested_stuff();
}
catch (Throwable e) {
    do stuff with e.getMessage()
}

AssertionErrorのドキュメントには、Throwable から派生したものであり、(文字列に変換された後) ctor 引数としてアサートされた式で常に構築されると書かれています。ここで getMessage() を呼び出して、 「あなたのコードがうまくいかないため、ファイル X 行 Y でアサーションが失敗しました」などの便利な情報を取得できるはずだと思います。

代わりに、getMessage() は null を返します。アサーションがトリガーされていることを確認できる唯一の方法は、ループしe.getStackTrace()て行番号を追跡することです。

getMessage はどうなっていますか? AssertionError には、それをトリガーした条件に関する何かが常に含まれているはずではありませんか?

4

1 に答える 1

1

AssertionErrorには、それをトリガーした条件に関する何かが常に含まれているとは限りませんか？

どうやらそうではありません-ドキュメントに基づいています。

表現

assert args != null;

詳細メッセージなしでAssertionErrorをスローします（argsがnullの場合）

assert args != null : "Arguments must not be null";

詳細メッセージとともにAssertionErrorをスローしますArguments must not be null

お見舞い申し上げます。コンパイラが次のような式をとるのに十分賢いのであれば、それは本当にクールでしょう。

assert args != null;

そして、メッセージ「args！= null」でAssertionErrorをスローしますが、それはそれがどのように機能するかではないと思います。

古いコードをすべて調べ、assert式を検出して、次のようなものに置き換えるスクリプトを作成できると思います。

assert <expression> : "<text of expression>";

そのような

assert args != null : "args != null";
于 2012-11-20T17:35:57.650 に答える