Marque dos argumentos en Java, ambos no nulos o ambos nulos elegantemente

Utilicé Spring Boot para desarrollar un proyecto de shell utilizado para enviar correos electrónicos, por ejemplo

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

Si faltan los argumentos fromy password, utilizo un remitente y una contraseña predeterminados, por ejemplo, noreply@bar.comy 123456.

Entonces, si el usuario pasa el fromargumento, también debe pasar el passwordargumento y viceversa. Es decir, ambos son no nulos o ambos son nulos.

¿Cómo verifico esto con elegancia?

Ahora mi camino es

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

Hay una manera de usar el operador ^( XOR ):

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

La ifcondición será verdadera si solo una variable es nula.

Pero creo que generalmente es mejor usar dos ifcondiciones con diferentes mensajes de excepción. No puede definir qué salió mal con una sola condición.

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");
}

Es más legible y mucho más fácil de entender, y solo requiere un poco más de tipeo.

Bueno, parece que estás tratando de verificar si la condición de "nulidad" de los dos es la misma o no. Podrías usar:

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

O hacerlo más explícito con variables auxiliares:

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

Personalmente, prefiero legible a elegante.

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

Ponga esa funcionalidad en un método de 2 argumentos con la firma:

void assertBothNullOrBothNotNull(Object a, Object b) throws RuntimeException

Esto ahorra espacio en el método real que le interesa y lo hace más legible. No hay nada de malo con nombres de métodos ligeramente verbosos y no hay nada de malo con métodos muy cortos.

Se utilizaría Objects.isNull(Object)una solución Java 8 , suponiendo una importación estática:

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

Para Java <8 (o si no le gusta usar Objects.isNull()), puede escribir fácilmente su propio isNull()método.

Aquí hay una solución general para cualquier número de cheques nulos

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));
}

Usos

// 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) { .. }

Dado que desea hacer algo especial (usar valores predeterminados) cuando faltan el remitente y la contraseña, primero debe manejar eso.
Después de eso, debe tener un remitente y una contraseña para enviar un correo electrónico; lanzar una excepción si falta alguno.

// 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();
}

Un beneficio adicional es que, si alguno de sus valores predeterminados es nulo, también se detectará.

Dicho esto, en general creo que el uso de XOR debería ser permisible cuando ese es el operador que necesita. Que es una parte de la lengua, no sólo un truco que funciona debido a un arcano compilador de errores.
Una vez tuve un orker que descubrió que el operador ternario era demasiado confuso para usar ...

Me gustaría sugerir otra alternativa que es cómo escribiría realmente este fragmento de código:

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

Para mí, esta parece ser la forma más natural de expresar esta condición, lo que hace que sea fácil de entender para alguien que tenga que leerla en el futuro. También le permite enviar mensajes de diagnóstico más útiles y tratar la contraseña innecesaria como menos grave y facilita la modificación, lo que es bastante probable para tal condición. Es decir, puede descubrir que dar una contraseña como argumento de línea de comando no es la mejor idea y puede permitir leer la contraseña desde la entrada estándar opcionalmente si falta el argumento. O es posible que desee ignorar silenciosamente el argumento de contraseña superfluo. Cambios como estos no requieren que reescribas todo el asunto.

Además de eso, ejecuta solo el número mínimo de comparaciones, por lo que no es más caro que las alternativas más "elegantes" . Aunque el rendimiento es un problema muy poco probable aquí porque comenzar un nuevo proceso ya es mucho más costoso que una verificación nula adicional.

Creo que una forma correcta de manejar esto es considerar tres situaciones: se proporcionan 'desde' y 'contraseña', ninguna de las dos, se proporciona una combinación de ambas.

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.
}

Parece que la pregunta original quiere romper el flujo si es una entrada incorrecta, pero luego tendrán que repetir algo de la lógica más adelante. Quizás una buena declaración de lanzamiento podría ser:

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"
);

Aquí hay una manera relativamente directa que no involucra ningún Xor og largo ifs. Sin embargo, requiere que sea un poco más detallado, pero por el lado positivo, puede usar las Excepciones personalizadas que sugerí para obtener un mensaje de error más significativo.

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);
  }
}

Nadie parece haber mencionado el operador ternario :

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

Funciona bien para verificar esta condición particular, pero no generaliza más allá de dos variables.

Como veo sus intenciones, no es necesario verificar siempre ambas nulidades exclusivas sino verificar si passwordes nulo si y solo si fromno lo es. Puede ignorar el passwordargumento dado y usar su propio valor predeterminado si fromes nulo.

Escrito en pseudo debe ser así:

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
}

Me sorprende que nadie haya mencionado la solución simple de crear fromy passwordcampos de una clase y pasar una referencia a una instancia de esa clase:

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

aquí from podría ser nulo o no nulo y si no es nulo, ambos campos tienen valores no nulos.

Una ventaja de este enfoque es que el error de hacer que un campo pero no el otro campo sea nulo se activa donde se obtiene inicialmente la cuenta, no cuando se ejecuta el código que usa la cuenta. Para cuando se ejecuta el código que usa la cuenta, es imposible que los datos no sean válidos.

Otra ventaja de este enfoque es más legible ya que proporciona más información semántica. Además, es probable que requiera el nombre y la contraseña juntos en otros lugares, por lo que el costo de definir una clase adicional se amortiza en varios usos.