java - tutorial - para que se usa elastic search

Pasar nulo a un método

Question

Estoy en el medio de leer el excelente Código de limpieza

Una discusión es sobre pasar nulos a un método.

public class MetricsCalculator {
    public double xProjection(Point p1, Point p2) {
        return (p2.x - p1.x) * 1.5;
    }
}
...
calculator.xProjection(null, new Point(12,13));

Representa diferentes formas de manejar esto:

public double xProjection(Point p1, Point p2) {
    if (p1 == null || p2 == null) {
        throw new IllegalArgumentException("Invalid argument for xProjection");
    }
    return (p2.x - p1.x) * 1.5;
}

public double xProjection(Point p1, Point p2) {
    assert p1 != null : "p1 should not be null";
    assert p2 != null : "p2 should not be null";
    return (p2.x - p1.x) * 1.5;
}

Prefiero el enfoque de aserciones , pero no me gusta el hecho de que las aserciones estén desactivadas por defecto.

El libro finalmente dice:

En la mayoría de los lenguajes de programación no hay una buena manera de lidiar con un nulo que es pasado accidentalmente por un llamador. Debido a que este es el caso, el enfoque racional es prohibir pasar nulo por defecto.

Realmente no entra en cómo harías cumplir esta restricción?

¿Alguno de ustedes tiene opiniones fuertes de cualquier manera?

Answer 1

En la mayoría de los lenguajes de programación no hay una buena manera de lidiar con un nulo que es pasado accidentalmente por un llamador. Debido a que este es el caso, el enfoque racional es prohibir pasar nulo por defecto.

Encontré las aproximaciones @Nullable y @NotNull de JetBrains para tratar este tema de la forma más ingeniosa, hasta ahora. Es IDE específico, desafortunadamente, pero realmente limpio y poderoso, IMO.

http://www.jetbrains.com/idea/documentation/howto.html

Tener esto (o algo similar) como un estándar de Java sería realmente agradable.

Answer 2

Realmente no entra en cómo harías cumplir esta restricción?

Lo aplica lanzando un ArgumentExcexception si pasan nulo.

if (p1 == null || p2 == null) {
    throw new IllegalArgumentException("Invalid argument for xProjection");
}

Answer 3

@Chris Karcher, diría absolutamente correcto. Lo único que diría es verificar los params por separado y hacer que el informe de excepciones incluya el parámetro que también era nulo, ya que hace que el seguimiento del origen del nulo sea mucho más fácil.

@wvdschel wow! Si escribir el código es demasiado esfuerzo para usted, debe buscar en algo como PostSharp (o un equivalente de Java si hay uno disponible) que pueda postprocesar sus ensamblajes e insertar los controles de param por usted.

Answer 4

@aku

entonces deberías lanzar System.ArgumentNullException

No veo cómo lanzar una excepción .NET Framework va a ayudarlo :)

De lo contrario, de forma Java, suponiendo que el nulo proviene de un error de programación (es decir, nunca debe salir de la fase de prueba), entonces deje que el sistema lo arroje, o si hay efectos secundarios que llegan a ese punto, verifique nulo en el comenzando y lanzando IllegalArgumentException o NullPointerException.

Si el valor nulo puede provenir de una excepción real al caso pero no desea usar una excepción marcada para eso, entonces definitivamente desea ir a la ruta IllegalArgumentException al comienzo del método.

Answer 5

@lassevk:

Sin embargo, si el método simplemente almacena los datos pasados, y hay otro método que llamará más tarde para tratarlo, descubrir la entrada incorrecta tan pronto como sea posible es la clave para corregir los errores más rápidamente. En ese punto posterior, podría haber una gran cantidad de maneras en que los datos erróneos se le dieron a su clase. Es como tratar de descubrir cómo las ratas llegaron a tu casa después del hecho, tratando de encontrar el agujero en alguna parte.

Tiene razón al respecto, estas comprobaciones solo deben aplicarse cuando los datos solo se almacenan para ser procesados ​​o utilizados más adelante. No pensé en ese escenario.

@Shaun Austin:

¡Guauu! Si escribir el código es demasiado esfuerzo para ti, ...

Escribir código no es el problema, escribir código de mono que me molesta. Escribir código que una máquina podría haber escrito mejor. Esa biblioteca parece que solo hace eso, ¡gracias por señalarla!

Answer 6

Además, no es de uso inmediato, pero está relacionado con la mención de Spec # ... Hay una propuesta para agregar "tipos null-safe" a una versión futura de Java: "Manejo nulo mejorado : tipos seguros contra el nulo" .

Según la propuesta, su método se convertiría

public class MetricsCalculator {
    public double xProjection(#Point p1, #Point p2) {
        return (p2.x - p1.x) * 1.5;
    }
}

donde #Point es el tipo de referencias no null a objetos de tipo Point .

Answer 7

Aunque no está estrictamente relacionado, es posible que desee echar un vistazo a Spec # .

Creo que todavía está en desarrollo (por parte de Microsoft), pero algunos CTP están disponibles y parece prometedor. Básicamente te permite hacer esto:

  public static int Divide(int x, int y)
    requires y != 0 otherwise ArgumentException; 
  {
  }

o

  public static int Subtract(int x, int y)
    requires x > y;
    ensures result > y;
  {
    return x - y;
  } 

También proporciona otras características como tipos Notnull. Se basa en .NET Framework 2.0 y es totalmente compatible. La sintaxis, como puede ver, es C #.

Answer 8

Como fuera de tema parece haberse convertido en el tema, Scala toma un enfoque interesante para esto. Se supone que todos los tipos no son nulos, a menos que lo ajuste explícitamente en una Option para indicar que podría ser nulo. Asi que:

//  allocate null
var name : Option[String]
name = None

//  allocate a value
name = Any["Hello"]

//  print the value if we can
name match {
  Any[x] => print x
  _ => print "Nothing at all"
}

Answer 9

Estoy de acuerdo o en desacuerdo con la publicación de wvdschel, depende de lo que esté diciendo específicamente.

En este caso, seguro, este método se bloqueará en nulo, por lo que la verificación explícita aquí probablemente no sea necesaria.

Sin embargo, si el método simplemente almacena los datos pasados, y hay otro método que llamará más tarde para tratarlo, descubrir la entrada incorrecta tan pronto como sea posible es la clave para corregir los errores más rápidamente. En ese punto posterior, podría haber una gran cantidad de maneras en que los datos erróneos se le dieron a su clase. Es como tratar de descubrir cómo las ratas llegaron a tu casa después del hecho, tratando de encontrar el agujero en alguna parte.

Answer 10

La mejor manera de manejar esto realmente sería el uso de excepciones. En última instancia, las afirmaciones van a terminar dando una experiencia similar al usuario final, pero no proporcionan ninguna forma para que el desarrollador llame a su código para manejar la situación antes de mostrar una excepción al usuario final. Ultimatley, quiere asegurarse de que prueba las entradas no válidas lo antes posible (especialmente en el código de cara al público) y proporcionar las excepciones adecuadas que el código de llamada pueda captar.

Answer 11

La regla general es si su método no espera argumentos nulos, entonces debe lanzar System.ArgumentNullException . Lanzar una excepción adecuada no solo lo protege de la corrupción de recursos y otras cosas malas, sino que sirve como una guía para los usuarios de su código, ahorrándole tiempo en depurar su código.

Lea también un artículo sobre programación defensiva

Answer 12

Por lo general, prefiero no hacer ninguna de las dos cosas, ya que solo está ralentizando las cosas. Las excepciones NullPointerExceptions se lanzan más tarde de todos modos, lo que conducirá rápidamente al usuario a descubrir que están pasando nulo al método. Solía ​​comprobar, pero el 40% de mi código terminaba siendo código de comprobación, y en ese momento decidí que no valía la pena los buenos mensajes de afirmación.

Answer 13

Prefiero el uso de aserciones.

Tengo una regla que solo uso aserciones en métodos públicos y protegidos. Esto se debe a que creo que el método de llamada debe garantizar que está pasando argumentos válidos a métodos privados.

Answer 14

Spec # parece muy interesante!

Cuando algo así no está disponible, generalmente pruebo métodos no privados con un null-check de tiempo de ejecución y aserciones para métodos internos. En lugar de codificar la verificación nula explícitamente en cada método, la delego a una clase de utilidades con un método de verificación nula:

/**
 * Checks to see if an object is null, and if so 
 * generates an IllegalArgumentException with a fitting message.
 * 
 * @param o The object to check against null.
 * @param name The name of the object, used to format the exception message
 *
 * @throws IllegalArgumentException if o is null.
 */
public static void checkNull(Object o, String name) 
    throws IllegalArgumentException {
   if (null == o)
      throw new IllegalArgumentException(name + " must not be null");
}

public static void checkNull(Object o) throws IllegalArgumentException {
   checkNull(o, "object");
} 

// untested:
public static void checkNull(Object... os) throws IllegalArgumentException {
   for(Object o in os) checkNull(o);  
}

Luego el control se convierte en:

public void someFun(String val1, String val2) throws IllegalArgumentException {
   ExceptionUtilities.checkNull(val1, "val1");
   ExceptionUtilities.checkNull(val2, "val2");

   /** alternatively:
   ExceptionUtilities.checkNull(val1, val2);
   **/

   /** ... **/
} 

Eso se puede agregar con macros de editor o un script de procesamiento de código. Editar: La verificación detallada también podría agregarse de esta manera, pero creo que es mucho más fácil automatizar la adición de una sola línea.

Answer 15

Tanto el uso de aserciones como el lanzamiento de excepciones son enfoques válidos aquí. Cualquiera de los dos mecanismos puede usarse para indicar un error de programación, no un error de tiempo de ejecución, como es el caso aquí.

• Las afirmaciones tienen la ventaja del rendimiento, ya que normalmente están inhabilitadas en los sistemas de producción.
• Las excepciones tienen la ventaja de la seguridad, ya que el control siempre se realiza.

La elección realmente depende de las prácticas de desarrollo del proyecto. El proyecto como un todo necesita decidir una política de aserción: si la opción es habilitar aserciones durante todo el desarrollo, entonces diría que use aserciones para verificar este tipo de parámetro inválido: en un sistema de producción, se lanza una NullPointerException debido a es poco probable que un error de programación pueda ser capturado y manejado de una manera significativa de todos modos, por lo que actuará como una afirmación.

Sin embargo, prácticamente sé que muchos desarrolladores que no confían en esas afirmaciones se habilitarán cuando corresponda y optarán por la seguridad de lanzar una NullPointerException.

Por supuesto, si no puede aplicar una política para su código (si está creando una biblioteca, por ejemplo, y depende de cómo otros desarrolladores ejecuten su código), debe optar por el enfoque seguro de lanzar NullPointerException para aquellos métodos que son parte de la API de la biblioteca.

Answer 16

Thwrowing C # ArgumentException , o Java IllegalArgumentException justo al comienzo del método me parece la solución más clara.

Uno siempre debe tener cuidado con las Excepciones de tiempo de ejecución: excepciones que no están declaradas en la firma del método. Como el compilador no lo obliga a atraparlos, es muy fácil olvidarse de ellos. Asegúrese de tener algún tipo de manejo de excepciones "catch all" para evitar que el software se detenga abruptamente. Esa es la parte más importante de tu experiencia de usuario.

Answer 17

Un poco fuera de tema, pero una característica de findbugs que creo que es muy útil es poder anotar los parámetros de los métodos para describir qué parámetros no se deben pasar con un valor nulo.

Usando el análisis estático de su código, findbugs puede señalar las ubicaciones donde se llama al método con un valor potencialmente nulo.

Esto tiene dos ventajas:

1. La anotación describe su intención sobre cómo debe llamarse el método, ayudando a la documentación
2. FindBugs puede apuntar a posibles llamadores problemáticos del método, lo que le permite rastrear posibles errores.

Solo es útil cuando tienes acceso al código que llama a tus métodos ... pero ese suele ser el caso.