Я использовал Spring Boot для разработки проекта оболочки, используемого для отправки электронной почты, например
sendmail -from foo@bar.com -password foobar -subject "hello world" -to aaa@bbb.com
Если from
и password
аргументы отсутствуют, я использую отправитель по умолчанию и пароль, например , noreply@bar.com
и 123456
.
Таким образом, если пользователь передает from
аргумент, он также должен передать password
аргумент и наоборот. То есть, либо оба ненулевые, либо оба нулевые.
Как я могу проверить это элегантно?
Теперь мой путь
if ((from != null && password == null) || (from == null && password != null)) {
throw new RuntimeException("from and password either both exist or both not exist");
}
From
Электронная почта не всегда имя аутентификации SMTP.Ответы:
Есть способ с помощью оператора
^
( XOR ):if
Условие будет верным , если только одна переменная равна нулю.Но я думаю, что обычно лучше использовать два
if
условия с разными сообщениями об исключениях. Вы не можете определить, что пошло не так, используя одно условие.Он более читабелен и намного проще для понимания, и для этого требуется лишь немного больше печатать.
источник
!=
на двух bools?!=
. Mindblown. И это очень большое количество голосов в комментарии. И, чтобы повысить качество этого комментария, да, я также считаю, что лучше давать разные сообщения об ошибках для разных случаев ошибки, так как пользователь будет лучше знать, как исправить ошибку.if
пункта - сообщение в исключении хорошоНу, звучит так, будто вы пытаетесь проверить, является ли условие "недействительности" двух одинаковым или нет. Вы можете использовать:
Или сделайте это более явным с помощью вспомогательных переменных:
источник
^
делает. :-)^
говорит: «Эй, мои операнды - логические выражения», но!=
это не так. (Хотя, к сожалению, этот эффект уменьшается из-за необходимости проверки «мои операнды могут быть числовыми, и я не могу быть оператором отношений на данный момент», что я предоставляю, является недостатком). Ваш статус героя не изменился, несмотря на несогласие со мной :-)from
иpassword
оба должны быть нулевыми или оба не должны быть нулевыми". Возможно, это только я и моя неопытность, но я предпочитаю более удобочитаемое решение, как в ответе @ stig-hemmer, даже если оно стоит еще 3 строки кода. Я думаю, я просто не сразу получаюbool != bool
- это не интуитивно понятно.^
Оператор является побитовым оператором; это на самом деле не означает, что его операнды логические. Логический оператор XORxor
.Лично я предпочитаю читабельность элегантному.
источник
IllegalArgumentException
вместо гологоRuntimeException
)Поместите эту функциональность в метод с двумя аргументами с подписью:
Это экономит место в интересующем вас фактическом методе и делает его более читабельным. Нет ничего плохого в слегка многословных именах методов, и нет ничего плохого в очень коротких методах.
источник
((from == null) != (password == null))
что очень просто для понимания. Что-то не так с бесполезными методами.Решение Java 8 будет использовать
Objects.isNull(Object)
, предполагая статический импорт:Для Java <8 (или если вы не любите использовать
Objects.isNull()
), вы можете легко написать свой собственныйisNull()
метод.источник
from == null != password == null
держит все это в одном кадре стека, ноObjects.isNull(Object)
без необходимости толкает и выталкивает два кадра. Objects.isNull (Object) существует потому, что «Этот метод существует для использования в качестве предиката» (т. Е. В потоках).Objects.isNull()
- вы можете написать свой собственный, если хотите, - но что касается читабельности, я думаю, что использованиеisNull()
лучше. Кроме того вам нужны дополнительные скобки , чтобы сделать простое выражение компиляции:from == null != (password == null)
.(val == null)
это очень большая возможность, предоставляемая для сравнения с нулем, и мне трудно преодолеть два больших толстых вызова метода, уставившихся мне в лицо, даже если метод довольно функциональный, встроенный и хорошо работающий. по имени. Это только я, хотя. Недавно я решил, что я немного странный.Вот общее решение для любого количества нулевых проверок
Пользы
источник
Поскольку вы хотите сделать что-то особенное (использовать значения по умолчанию), когда отсутствуют и отправитель, и пароль, обработайте это в первую очередь.
После этого у вас должен быть как отправитель, так и пароль для отправки электронной почты; бросить исключение, если либо отсутствует.
Дополнительным преимуществом является то, что, если любое из ваших значений по умолчанию будет нулевым, это также будет обнаружено.
Сказав это, в общем, я думаю, что использование XOR должно быть допустимо, когда это тот оператор, который вам нужен. Это является частью языка, а не только какой - то трюк , который работает из - за загадочного компилятора жука.
У меня когда-то был коровник, который нашел троичного оператора слишком запутанным, чтобы использовать ...
источник
Я хотел бы предложить другую альтернативу, которая заключается в том, как бы я на самом деле написал этот кусок кода:
Мне кажется, что это наиболее естественный способ выразить это состояние, которое облегчает понимание тем, кому, возможно, придется читать его в будущем. Это также позволяет вам выдавать более полезные диагностические сообщения и рассматривать ненужный пароль как менее серьезный, а также позволяет легко изменять, что весьма вероятно для такого состояния. Т.е. вы можете обнаружить, что указание пароля в качестве аргумента командной строки - не лучшая идея, и может потребоваться разрешить чтение пароля из стандартного ввода, если аргумент отсутствует. Или вы можете молча проигнорировать лишний аргумент пароля. Подобные изменения не потребуют от вас переписывания всего этого.
Кроме того, он выполняет только минимальное количество сравнений, поэтому он не дороже, чем более «элегантные» альтернативы. Хотя производительность здесь маловероятна, поскольку запуск нового процесса уже намного дороже, чем дополнительная проверка на ноль.
источник
Я думаю, что правильный способ справиться с этим - рассмотреть три ситуации: оба «from» и «password» предоставлены, ни один не предоставлен, оба из них предоставлены.
Звучит так, будто исходный вопрос хочет прервать поток, если он введен неправильно, но тогда им придется повторить часть логики позже. Возможно, хороший бросок может быть следующим:
источник
Вот сравнительно простой способ, который не требует каких-либо длинных if. Однако он требует, чтобы вы были немного более многословны, но с другой стороны, вы можете использовать пользовательские исключения, которые я предложил, чтобы получить более значимое сообщение об ошибке.
источник
Кажется, никто не упомянул троичный оператор :
Хорошо работает для проверки этого конкретного условия, но не обобщает хорошо за две переменные.
источник
^
,!=
с двумя BOOLS или дваif
сa == null ? (b == null? "both null" : "a null while b is not") : (b ==null? "b null while a is not")
Как я понимаю ваши намерения, нет необходимости всегда проверять обе исключительные значения, а проверять,
password
является ли значение null, если и только еслиfrom
оно не равно NULL. Вы можете игнорировать данныйpassword
аргумент и использовать свой собственный параметр по умолчанию, если значениеfrom
равно нулю.Написано псевдо должно быть так:
источник
password
без предоставленияfrom
, тогда он, возможно, намеревался переопределить пароль, но сохранить учетную запись по умолчанию. Если пользователь делает это, это неверная инструкция, и ему следует сообщить об этом. Программа не должна работать так, как если бы ввод был верным, и попытаться использовать учетную запись по умолчанию с паролем, который пользователь не указал. Я клянусь в таких программах.Я удивлен, что никто не упомянул простое решение создания
from
иpassword
полей класса и передачи ссылки на экземпляр этого класса:Здесь
from
может быть ноль или ненулевое значение, и если оно ненулевое, оба его поля имеют ненулевые значения.Одним из преимуществ этого подхода является то, что ошибка, связанная с тем, что одно поле, но не другое поле, становится пустым, возникает при первоначальном получении учетной записи, а не при запуске кода, использующего эту учетную запись. К тому времени, когда код, использующий учетную запись, будет выполнен, данные станут недействительными.
Другое преимущество этого подхода более читабельно, так как предоставляет больше семантической информации. Кроме того, вполне вероятно, что вам требуется имя и пароль вместе в других местах, поэтому стоимость определения дополнительного класса амортизируется в течение нескольких раз.
источник
new Account(null, null)
выдает NPE, даже если учетная запись с нулевым именем и паролем все еще действительна.null
вместоAccount
. Вы не перейдетеnull
кAccount
конструктору.