Sprawdź dwa argumenty w Javie, albo oba nie mają wartości null, albo oba elegancko

Spring boot wykorzystałem do stworzenia projektu powłoki służącego do wysyłania e-maili, np

sendmail -from foo@bar.com -password  foobar -subject "hello world"  -to aaa@bbb.com

Jeśli fromipassword brakuje argumentów , używam domyślnego nadawcy i hasła, np. noreply@bar.comI123456 .

Więc jeśli użytkownik przekaże plik from argument, musi również przekazaćpassword argument i odwrotnie. Oznacza to, że albo oba są niezerowe, albo oba są zerowe.

Jak to elegancko sprawdzić?

Teraz moja droga jest

if ((from != null && password == null) || (from == null && password != null)) {
    throw new RuntimeException("from and password either both exist or both not exist");
}

Istnieje sposób wykorzystania operatora ^( XOR ):

if (from == null ^ password == null) {
    // Use RuntimeException if you need to
    throw new IllegalArgumentException("message");
}

Plik ifWarunek będzie prawdziwa, jeśli tylko jedna zmienna ma wartość null.

Ale myślę, że zwykle lepiej jest użyć dwóch if warunków z różnymi komunikatami o wyjątkach. Nie możesz zdefiniować, co poszło nie tak, używając jednego warunku.

if ((from == null) && (password != null)) {
    throw new IllegalArgumentException("If from is null, password must be null");
}
if ((from != null) && (password == null)) {
    throw new IllegalArgumentException("If from is not null, password must not be null");
}

Jest bardziej czytelny i dużo łatwiejszy do zrozumienia i wymaga tylko trochę dodatkowego wpisywania.

Cóż, wygląda na to, że próbujesz sprawdzić, czy warunek „nieważności” tych dwóch jest taki sam, czy nie. Możesz użyć:

if ((from == null) != (password == null))
{
    ...
}

Lub wyjaśnij to bardziej za pomocą zmiennych pomocniczych:

boolean gotFrom = from != null;
boolean gotPassword = password != null;
if (gotFrom != gotPassword)
{
    ...
}

Osobiście wolę czytelny niż elegancki.

if (from != null && password == null) {
    throw new RuntimeException("-from given without -password");
}
if (from == null && password != null) {
    throw new RuntimeException("-password given without -from");
}

Umieść tę funkcjonalność w metodzie 2-argumentowej z podpisem:

void assertBothNullOrBothNotNull(Object a, Object b) throws RuntimeException

Oszczędza to miejsce w rzeczywistej metodzie, którą jesteś zainteresowany i czyni ją bardziej czytelną. Nie ma nic złego w lekko rozwlekłych nazwach metod i nie ma nic złego w bardzo krótkich metodach.

Należy użyć rozwiązania Java 8 Objects.isNull(Object), zakładając import statyczny:

if (isNull(from) != isNull(password)) {
    throw ...;
}

W przypadku języka Java <8 (lub jeśli nie lubisz używać Objects.isNull()), możesz łatwo napisać własnyisNull() metodę.

Oto ogólne rozwiązanie dla dowolnej liczby sprawdzeń zerowych

public static int nulls(Object... objs)
{
    int n = 0;
    for(Object obj : objs) if(obj == null) n++;
    return n;
}

public static void main (String[] args) throws java.lang.Exception
{
    String a = null;
    String b = "";
    String c = "Test";

    System.out.println (" "+nulls(a,b,c));
}

Używa

// equivalent to (a==null & !(b==null|c==null) | .. | c==null & !(a==null|b==null))
if (nulls(a,b,c) == 1) { .. }

// equivalent to (a==null | b==null | c==null)
if (nulls(a,b,c) >= 1) { .. }

// equivalent to (a!=null | b!=null | c!=null)
if (nulls(a,b,c) < 3) { .. }

// equivalent to (a==null & b==null & c==null)
if (nulls(a,b,c) == 3) { .. }

// equivalent to (a!=null & b!=null & c!=null)
if (nulls(a,b,c) == 0) { .. }

Ponieważ chcesz zrobić coś specjalnego (użyj wartości domyślnych), gdy nie ma nadawcy i hasła, zajmij się tym najpierw.
Następnie powinieneś mieć zarówno nadawcę, jak i hasło, aby wysłać wiadomość e-mail; zgłoś wyjątek, jeśli brakuje któregokolwiek z nich.

// use defaults if neither is provided
if ((from == null) && (password == null)) {
    from = DEFAULT_SENDER;
    password = DEFAULT_PASSWORD;
}

// we should have a sender and a password now
if (from == null) {
    throw new MissingSenderException();
}
if (password == null) {
    throw new MissingPasswordException();
}

Dodatkową korzyścią jest to, że jeśli którekolwiek z ustawień domyślnych ma wartość null, zostanie również wykryte.

Powiedziawszy to, generalnie uważam, że użycie XOR powinno być dozwolone, gdy jest to operator, którego potrzebujesz. Jest to część języka, a nie tylko sztuczka, która działa z powodu tajemniczego błędu kompilatora.
Miałem kiedyś krowoszka, dla którego operator trójskładnikowy był zbyt zagmatwany, by go używać ...

Chciałbym zasugerować inną alternatywę, w której faktycznie napisałbym ten fragment kodu:

if( from != null )
{
    if( password == null )
        error( "password required for " + from );
}
else
{
    if( password != null )
        warn( "the given password will not be used" );
}

Wydaje mi się, że jest to najbardziej naturalny sposób wyrażenia tego warunku, który ułatwia zrozumienie dla kogoś, kto być może będzie musiał go przeczytać w przyszłości. Pozwala również na przekazywanie bardziej pomocnych komunikatów diagnostycznych i traktowanie niepotrzebnego hasła jako mniej poważnego oraz ułatwia modyfikację, która jest raczej prawdopodobna w takim stanie. Tzn. Może się okazać, że podanie hasła jako argumentu wiersza poleceń nie jest najlepszym pomysłem i może zechcieć pozwolić na odczytanie hasła ze standardowego wejścia opcjonalnie, jeśli brakuje argumentu. Lub możesz po cichu zignorować zbędny argument dotyczący hasła. Takie zmiany nie wymagałyby przepisywania całości.

Poza tym wykonuje tylko minimalną liczbę porównań, więc nie jest droższy niż bardziej „eleganckie” alternatywy. Chociaż wydajność jest tutaj bardzo mało prawdopodobna, ponieważ rozpoczęcie nowego procesu jest już znacznie droższe niż dodatkowe sprawdzenie zerowe.

Myślę, że prawidłowym sposobem rozwiązania tego problemu jest rozważenie trzech sytuacji: podano zarówno „od”, jak i „hasło”, żadne z nich nie są podane, podano połączenie tych dwóch.

if(from != null && password != null){
    //use the provided values
} else if(from == null && password == null){
    //both values are null use the default values
} else{
   //throw an exception because the input is not correct.
}

Wygląda na to, że pierwotne pytanie chce przerwać przepływ, jeśli jest to niepoprawne dane wejściowe, ale później będą musieli powtórzyć część logiki. Być może dobrym stwierdzeniem dotyczącym rzutu może być:

throw new IllegalArgumentException("form of " + form + 
    " cannot be used with a "
    + (password==null?"null":"not null") +  
    " password. Either provide a value for both, or no value for both"
);

Oto stosunkowo prosty sposób, który nie obejmuje żadnych Xor i długich ifs. Wymaga to jednak nieco większej szczegółowości, ale z drugiej strony możesz użyć niestandardowych wyjątków, które zasugerowałem, aby uzyskać bardziej znaczący komunikat o błędzie.

private void validatePasswordExists(Parameters params) {
   if (!params.hasKey("password")){
      throw new PasswordMissingException("Password missing");
   }
}

private void validateFromExists(Parameters params) {
   if (!params.hasKey("from")){
      throw new FromEmailMissingException("From-email missing");
   }
}

private void validateParams(Parameters params) {

  if (params.hasKey("from") || params.hasKey("password")){
     validateFromExists(params);
     validatePasswordExists(params);
  }
}

Wydaje się, że nikt nie wspomniał o operatorze trójskładnikowym :

if (a==null? b!=null:b==null)

Dobrze sprawdza się przy sprawdzaniu tego konkretnego warunku, ale nie generalizuje dobrze poza dwiema zmiennymi.

Jak widzę twoje intencje, nie ma potrzeby zawsze sprawdzać obu wyłącznych nieważności, ale sprawdzanie, czy passwordjest zerowe wtedy i tylko wtedy, gdy fromnie jest zerowe. Możesz zignorować podany passwordargument i użyć własnej wartości domyślnej, jeślifrom ma wartość null.

Napisane pseudo musi wyglądać tak:

if (from == null) { // form is null, ignore given password here
    // use your own defaults
} else if (password == null) { // form is given but password is not
    // throw exception
} else { // both arguments are given
    // use given arguments
}

Dziwię się, że nikt nie wspomniał o prostym rozwiązaniu tworzenia fromi passwordpól klasy oraz przekazywania odwołania do instancji tej klasy:

class Account {
    final String name, password;
    Account(String name, String password) {
        this.name = Objects.requireNonNull(name, "name");
        this.password = Objects.requireNonNull(password, "password");
    }
}

// the code that requires an account
Account from;
// do stuff

Tutaj from może mieć wartość null lub niezerową, a jeśli jest różna od null, oba jego pola mają wartości inne niż null.

Jedną z zalet tego podejścia jest to, że błąd polegający na utworzeniu jednego pola, ale nie drugiego pola o wartości null, jest wyzwalany w momencie, gdy konto jest początkowo uzyskiwane, a nie podczas wykonywania kodu używającego konta. Do czasu wykonania kodu korzystającego z konta niemożliwe jest, aby dane były nieprawidłowe.

Kolejna zaleta tego podejścia jest bardziej czytelna, ponieważ dostarcza więcej informacji semantycznych. Jest również prawdopodobne, że będziesz potrzebować nazwy i hasła razem w innych miejscach, więc koszt zdefiniowania dodatkowej klasy amortyzuje się przy wielokrotnym użyciu.