12

たとえば、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");
}
4

5 に答える 5

21
于 2010-06-27T18:07:16.580 に答える
4

ドキュメントには、記号の代わりに単語を使用して非常に明確にする例が示されています。

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

これらは基本的にログ (またはデバッグ セッション) の例外メッセージに過ぎないことを考えると、問題を見ている人、またはコードを読んで前提条件を理解する人にとって最も明確になると思われることは何でもしてください。

たとえば、上記を次のように書き換えることができます。

checkArgument(count > 0, "count must be positive; was actually %s", count);
于 2010-06-27T17:15:06.547 に答える
2

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

checkArgument(a == b, "a (%s) must equal b (%s)", a, b);
于 2010-06-27T18:15:47.603 に答える
0

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

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

誰もテキストを本当に気にしない場合に常にエラーメッセージを提供する必要があるため、プログラマーは役に立たない、明白で役に立たないメッセージを作成し、コードを読みにくくするだけです。

エラーメッセージが役立つ場合があります。たとえば、メッセージに変数の実際の値が含まれている場合がありますが、経験上、それほど頻繁ではありません。このような場合は、メッセージを使用できます。

同様の議論は、JUnitのassertメソッドにも当てはまります。常にエラーメッセージを提供することは良い考えではありません。

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

于 2010-08-25T15:54:34.613 に答える