Что надлежащее сообщение об ошибке должно предоставить к Предварительным условиям Гуавы Google.* методы?
Например, при использовании 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 ответа
Для проверок предусловий указание требования в подробном сообщении об исключении более информативно, чем простое изложение фактов. Это также приводит к гораздо более естественному чтению кода:
В документации приведен следующий пример:
Это позволяет использовать такие конструкции, как
if (count <= 0) { throw new IllegalArgumentException("должно быть положительным: " + count); }заменить на более компактную
checkArgument(count > 0, "must be positive: %s", count);
Обращают на себя внимание два момента:
- В примере явно указано требование, а не факт.
- "что-то должно быть правильным", вместо "что-то является неправильным"
- Перевернув условие проверки, вся конструкция читается более естественно
Следуя этому примеру, лучшее сообщение было бы таким:
checkArgument(a == b, "a must be equal to b"); // natural!
Вы даже можете пойти дальше и зафиксировать значения a и b в сообщении об исключении (см. Effective Java 2nd Edition, Item 63: Include failure capture information in detail messages):
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 одно булево выражение, за которым следует строка, противоречащая этому выражению.
Другим недостатком указания фактов является то, что для сложных предварительных условий это потенциально менее информативно, поскольку пользователь может уже знать о факте, но не о том, какие именно требования нарушаются.
Похожие вопросы
Лично для чего-то вроде этого я бы написал
checkArgument(a == b, "a (%s) must equal b (%s)", a, b);
В документации приводятся примеры, которые очень четко поясняют использование слов вместо символов:
checkArgument(count > 0, "must be positive: %s", count);
Учитывая, что это в основном просто сообщения об исключениях в журналах (или сеансах отладки), делайте все, что, по вашему мнению, сделает это наиболее ясным для всех, кто смотрит на проблему, или для всех, кто читает код, чтобы понять предварительное условие.
Например, вы можете переписать приведенное выше как:
checkArgument(count > 0, "count must be positive; was actually %s", count);
Часто (большую часть времени) вы можете просто использовать метод checkArgument () без параметра сообщения об ошибке, то есть вообще не предоставляя сообщения об ошибке.
Чтобы составить хорошее сообщение об ошибке, нужно понимать, кто прочитает сообщение. Это не конечный пользователь; если предварительное условие не выполняется, это, скорее всего, указывает на ошибку в коде. Текст может объяснить неудачное предварительное условие, но в большинстве случаев он бесполезен для конечного пользователя, он должен быть подсказкой для программиста. В большинстве случаев само сообщение также не имеет смысла без трассировки стека и исходного кода. Фактически, в большинстве случаев трассировка стека и исходный код - это именно то, что нужно программисту для исправления ошибки, сообщение об ошибке не помогает. Если предварительное условие неочевидно, комментарий рядом с ним - отличный способ его задокументировать.
Необходимость всегда выдавать сообщение об ошибке в случаях, когда никого не интересует текст, приводит к тому, что программисты создают бесполезные, очевидные и бесполезные сообщения, что только делает код менее читабельным.
Есть некоторые случаи, когда сообщение об ошибке может быть полезным, например, сообщение может содержать фактические значения переменных, но, по нашему опыту, это не очень часто, и в этих случаях вы можете использовать сообщение.
Подобные аргументы применяются также в методах assert в JUnit; всегда выдавать сообщение об ошибке - не лучшая идея.
Кроме того, когда вы используете предварительные условия в библиотеке, а не в приложении для конечных пользователей, все может быть иначе, поскольку вы не знаете, как будет использоваться ваш код.