Google Guavaの前提条件に供給するための適切なエラーメッセージは何ですか。*メソッドは何ですか？

StackOverflow https://stackoverflow.com/questions/3128120

質問

たとえば、使用する場合 Preconditions.Checkargument, 、エラーメッセージは、通過ケースまたはチェックの問題の失敗したケースを反映することになっていますか？

import static com.google.common.base.Preconditions.*;

void doStuff(int a, int b) {
  checkArgument(a == b, "a == b");
  // OR
  checkArgument(a == b, "a != b");
}
役に立ちましたか？

解決

前提条件チェックの場合、 要件 例外では、詳細メッセージは、単に事実を述べるよりも有益です。また、コードをより自然に読み取ることにもつながります。

ドキュメンテーション 次の例を提供します。

これにより、次のようなコンストラクトが可能になります

 if (count <= 0) {
   throw new IllegalArgumentException("must be positive: " + count);
 }

よりコンパクトに置き換える

 checkArgument(count > 0, "must be positive: %s", count);

2つのことは注意してください：

  • この例は、事実ではなく、要件を明確に述べています
    • "なにか でなければなりません 右"、 それ以外の "なにか は 間違い"
  • チェックの条件を反転させることにより、コンストラクト全体がより自然に読む

その例に従って、より良いメッセージは次のとおりです。

checkArgument(a == b, "a must be equal to b"); // natural!

さらに一歩進んで、の値をキャプチャすることもできます a と b 例外メッセージを参照してください 効果的なJava 2nd Edition、項目63：障害キャプチャ情報を詳細に含める):

checkArgument(a == b, "a must be equal to b; instead %s != %s", a, b);

事実を述べる代替手段は、コードで読むのはそれほど自然ではありません。

checkArgument(a == b, "a != b");              // awkward!
checkArgument(a == b, "a is not equal to b"); // awkward!

Java Code 1つのブール式で読むのがどれほど厄介であるかに注意してください。その後、その式と矛盾する文字列が続きます。

事実を述べるもう1つの欠点は、複雑な前提条件の場合、ユーザーは既に事実を知っている可能性があるため、潜在的に有益ではないということです。

関連する質問

他のヒント

ドキュメントは、シンボルの代わりに単語を使用して非常に明確にする例を示しています。

checkArgument(count > 0, "must be positive: %s", count);

これらは基本的にログの例外メッセージ（またはデバッグセッション）であることを考えると、問題を見ている人や、前提条件を理解するためにコードを読んでいる人に最も明確になると思われることは何でも実行します。

たとえば、あなた たぶん......だろう 上記を書き換えます：

checkArgument(count > 0, "count must be positive; was actually %s", count);

個人的には、このようなもののために私は書くと思います

checkArgument(a == b, "a (%s) must equal b (%s)", a, b);

多くの場合（ほとんどの場合）checkargument（）メソッドを使用することができます それなし エラーメッセージパラメーター、つまり、エラーメッセージがまったく提供されていません。

適切なエラーメッセージを作成するには、誰がメッセージを読むかを理解する必要があります。エンドユーザーではありません。前提条件が失敗した場合、コードのバグを指します。テキストは失敗した前提条件を説明するかもしれませんが、ほとんどの場合、エンドユーザーには役に立たないため、プログラマーにとってヒントになるはずです。ほとんどの場合、メッセージ自体もStacktraceとソースコードなしでは意味がありません。実際、ほとんどの場合、Stacktraceとソースコードは、プログラマーがバグを修正するために必要なものであるため、エラーメッセージは役に立ちません。前提条件が明らかでない場合、その隣のコメントはそれを文書化するのに最適な方法です。

誰も実際にテキストを気にしない場合に常にエラーメッセージを提供する必要性は、プログラマーが役に立たず、明らかで、役に立たないメッセージを、コードの読み取りのみを軽減できるようにすることにつながります。

エラーメッセージが役立つ場合、たとえばメッセージに変数の実際の値を含めることができますが、あまり頻繁ではない経験から、メッセージを使用できます。

Junitのアサート方法にも同様の議論が適用されます。常にエラーメッセージを提供することは良い考えではありません。

また、エンドユーザーのアプリケーションではなくライブラリで前提条件を使用している場合、コードがどのように使用されるかわからないため、事態は異なる場合があります。

として 多遺伝子硬化剤 指摘した：

事前調整の場合、例外の詳細メッセージで要件を記載することは、単に事実を述べるよりも有益です。

Guavaの前提条件で確かにこれを行うことができますが、 要件API （私が執筆した）を使用すると、自分の努力なしでより良い出力を達成できます。

グアバの前提条件

String a = "foosball";
String b = "ballroom";
Preconditions.checkArgument(a == b, "a == b");

これを与えます：

java.lang.IllegalArgumentException: a == b
    at com.google.common.base.Preconditions.checkArgument(Preconditions.java:122)
    at Main.main(Main.java:142)

要件API

String a = "foosball";
String b = "ballroom";
requireThat(a, "a").isEqualTo(b, "b")

これを与えます：

output

同じ入力、より良い出力。

（端末が色をサポートしていない場合、代わりにテキストの違いが得られます）

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top