java división entre - Evitando! = Declaraciones nulas




15 Answers

Si usa (o planea usar) un IDE de Java como JetBrains IntelliJ IDEA , Eclipse o Netbeans o una herramienta como Findbugs, puede usar anotaciones para resolver este problema.

Básicamente, tienes @Nullable y @NotNull .

Se puede utilizar en método y parámetros, como este:

@NotNull public static String helloWorld() {
    return "Hello World";
}

o

@Nullable public static String helloWorld() {
    return "Hello World";
}

El segundo ejemplo no compilará (en IntelliJ IDEA).

Cuando usas la primera función helloWorld() en otro fragmento de código:

public static void main(String[] args)
{
    String result = helloWorld();
    if(result != null) {
        System.out.println(result);
    }
}

Ahora el compilador de IDEA de IntelliJ le dirá que la comprobación es inútil, ya que la función helloWorld() no volverá a ser null , nunca.

Usando parametro

void someMethod(@NotNull someParameter) { }

si escribes algo como:

someMethod(null);

Esto no compilará.

Último ejemplo usando @Nullable

@Nullable iWantToDestroyEverything() { return null; }

Haciendo esto

iWantToDestroyEverything().something();

Y puedes estar seguro de que esto no sucederá. :)

Es una buena manera de dejar que el compilador verifique algo más de lo que suele hacer y hacer que sus contratos sean más sólidos. Desafortunadamente, no es compatible con todos los compiladores.

En IntelliJ IDEA 10.5 y en adelante, agregaron soporte para cualquier otra implementación de @Nullable @NotNull .

Ver publicación en el blog Más flexible y configurable @ Nullable / @ NotNull anotaciones .

cero uso excepción

Uso object != null mucho para evitar NullPointerException .

¿Hay una buena alternativa a esto?

Por ejemplo:

if (someobject != null) {
    someobject.doCalc();
}

Esto evita una NullPointerException , cuando se desconoce si el objeto es null o no.

Tenga en cuenta que la respuesta aceptada puede estar desactualizada, consulte https://.com/a/2386013/12943 para obtener un enfoque más reciente.




Wow, casi odio agregar otra respuesta cuando tenemos 57 formas diferentes de recomendar el NullObject pattern , pero creo que a algunas personas interesadas en esta pregunta les gustaría saber que hay una propuesta para Java 7 sobre la mesa para agregar "null". "Manejo seguro": una sintaxis optimizada para la lógica if-not-equal-null.

El ejemplo dado por Alex Miller se ve así:

public String getPostcode(Person person) {  
  return person?.getAddress()?.getPostcode();  
}  

El ?. significa solo desvincular el identificador izquierdo si no es nulo, de lo contrario evalúe el resto de la expresión como null . Algunas personas, como Dick Wall, miembro de Java Posse y los votantes de Devoxx, realmente aman esta propuesta, pero también hay oposición, ya que en realidad fomentará un mayor uso de null como valor centinela.

Actualización: Se proposed una proposed para un operador seguro en nulo en Java 7 en el marco de Project Coin. La sintaxis es un poco diferente a la del ejemplo anterior, pero es la misma noción.

Actualización: La propuesta del operador de seguridad nula no se convirtió en Project Coin. Por lo tanto, no verás esta sintaxis en Java 7.




Solo para esta situación -

No se comprueba si una variable es nula antes de invocar un método igual (un ejemplo de comparación de cadena a continuación):

if ( foo.equals("bar") ) {
 // ...
}

resultará en una NullPointerException si foo no existe.

Puedes evitar eso si comparas tus String esta manera:

if ( "bar".equals(foo) ) {
 // ...
}



Dependiendo del tipo de objetos que esté verificando, es posible que pueda utilizar algunas de las clases en los comunes de apache, como: lang de apache commons y colecciones de apache commons

Ejemplo:

String foo;
...
if( StringUtils.isBlank( foo ) ) {
   ///do something
}

o (dependiendo de lo que necesite verificar):

String foo;
...
if( StringUtils.isEmpty( foo ) ) {
   ///do something
}

La clase StringUtils es solo una de muchas; Hay bastantes buenas clases en los comunes que no permiten una manipulación segura.

A continuación, se muestra un ejemplo de cómo puede usar la nulidad nula en JAVA cuando incluye la biblioteca de apache (commons-lang-2.4.jar)

public DOCUMENT read(String xml, ValidationEventHandler validationEventHandler) {
    Validate.notNull(validationEventHandler,"ValidationHandler not Injected");
    return read(new StringReader(xml), true, validationEventHandler);
}

Y si está utilizando Spring, Spring también tiene la misma funcionalidad en su paquete, consulte la biblioteca (spring-2.4.6.jar)

Ejemplo sobre cómo usar este classf estático de spring (org.springframework.util.Assert)

Assert.notNull(validationEventHandler,"ValidationHandler not Injected");



Soy un fan del código "fail fast". Pregúntese: ¿está haciendo algo útil en el caso de que el parámetro sea nulo? Si no tiene una respuesta clara para lo que su código debe hacer en ese caso ... Es decir, nunca debe ser nulo en primer lugar, luego ignórelo y permita que se lance una NullPointerException. El código de llamada tendrá tanto sentido de una NPE como lo haría una IllegalArgumentException, pero será más fácil para el desarrollador depurar y entender qué salió mal si se lanza una NPE en lugar de que su código intente ejecutar otra contingencia inesperada Lógica: lo que finalmente hace que la aplicación falle de todos modos.




A veces, tiene métodos que operan en sus parámetros que definen una operación simétrica:

a.f(b); <-> b.f(a);

Si sabes que b nunca puede ser nulo, simplemente puedes cambiarlo. Es más útil para iguales: en lugar de foo.equals("bar"); mejor hacer "bar".equals(foo); .




Java 7 tiene una nueva clase de utilidad java.util.Objects en la que existe un método requireNonNull() .Todo lo que hace es lanzar un NullPointerExceptionsi su argumento es nulo, pero limpia el código un poco. Ejemplo:

Objects.requireNonNull(someObject);
someObject.doCalc();

El método es más útil para checking justo antes de una asignación en un constructor, donde cada uso puede guardar tres líneas de código:

Parent(Child child) {
   if (child == null) {
      throw new NullPointerException("child");
   }
   this.child = child;
}

se convierte en

Parent(Child child) {
   this.child = Objects.requireNonNull(child, "child");
}



En última instancia, la única forma de resolver completamente este problema es mediante el uso de un lenguaje de programación diferente:

  • En Objective-C, puedes hacer el equivalente de invocar un método nily no pasará absolutamente nada. Esto hace que la mayoría de las comprobaciones nulas no sean necesarias, pero puede hacer que los errores sean mucho más difíciles de diagnosticar.
  • En Nice , un lenguaje derivado de Java, hay dos versiones de todos los tipos: una versión potencialmente nula y una versión no nula. Sólo puede invocar métodos en tipos no nulos. Los tipos potencialmente nulos se pueden convertir en tipos no nulos mediante la comprobación explícita de nulos. Esto hace que sea mucho más fácil saber dónde son necesarios los controles nulos y dónde no lo son.



Hacer esa pregunta indica que puede estar interesado en estrategias de manejo de errores. El arquitecto de tu equipo debe decidir cómo trabajar los errores. Hay varias formas de hacerlo:

  1. permitir que las Excepciones se trasladen a través de ellas: atraparlas en el 'bucle principal' o en alguna otra rutina de administración.

    • Verificar condiciones de error y manejarlas adecuadamente.

Seguro que también eche un vistazo a la Programación Orientada a Aspectos, ya que tienen formas sencillas de insertarlo if( o == null ) handleNull()en su código de bytes.




Simplemente nunca uses null. No lo permitas

En mis clases, la mayoría de los campos y las variables locales tienen valores predeterminados que no son nulos, y agrego declaraciones de contrato (aseveraciones siempre activas) en todas partes del código para asegurarme de que esto se cumpla (ya que es más sucinto y más expresivo que dejarlo) aparece como NPE y luego tiene que resolver el número de línea, etc.).

Una vez que adopté esta práctica, noté que los problemas parecían solucionarse solos. Cogió cosas mucho antes en el proceso de desarrollo solo por accidente y se dio cuenta de que tenía un punto débil ... y, lo que es más importante, ayuda a encapsular las inquietudes de los diferentes módulos, los diferentes módulos pueden "confiar" entre sí, y no dejar de ensuciar los Código con if = null elseconstructos!

Esta es una programación defensiva y resulta en un código mucho más limpio a largo plazo. Siempre desinfecte los datos, p. Ej. Aquí mediante la aplicación de estándares rígidos, y los problemas desaparecen.

class C {
    private final MyType mustBeSet;
    public C(MyType mything) {
       mustBeSet=Contract.notNull(mything);
    }
   private String name = "<unknown>";
   public void setName(String s) {
      name = Contract.notNull(s);
   }
}


class Contract {
    public static <T> T notNull(T t) { if (t == null) { throw new ContractException("argument must be non-null"); return t; }
}

Los contratos son como mini pruebas unitarias que siempre se están ejecutando, incluso en producción, y cuando las cosas fallan, sabes por qué, en lugar de un NPE aleatorio, tienes que descifrarlo.




Este es un problema muy común para todos los desarrolladores de Java. Por lo tanto, hay soporte oficial en Java 8 para abordar estos problemas sin código desordenado.

Java 8 ha introducido java.util.Optional<T>. Es un contenedor que puede o no contener un valor no nulo. Java 8 ha brindado una forma más segura de manejar un objeto cuyo valor puede ser nulo en algunos de los casos. Está inspirado en las ideas de Haskell y Scala .

En pocas palabras, la clase opcional incluye métodos para tratar explícitamente los casos en que un valor está presente o ausente. Sin embargo, la ventaja en comparación con las referencias nulas es que la clase <T> Opcional lo obliga a pensar en el caso cuando el valor no está presente. Como consecuencia, puede evitar excepciones de puntero nulo no deseadas.

En el ejemplo anterior, tenemos una fábrica de servicios para el hogar que devuelve un identificador a varios dispositivos disponibles en el hogar. Pero estos servicios pueden o no estar disponibles / funcionales; significa que puede resultar en una NullPointerException. En lugar de agregar una ifcondición nula antes de usar cualquier servicio, envolvámoslo en <Servicio> Opcional.

ENVÍO A OPCIÓN <T>

Consideremos un método para obtener una referencia de un servicio de una fábrica. En lugar de devolver la referencia de servicio, envuélvala con Opcional. Le permite al usuario de la API saber que el servicio devuelto puede o no estar disponible / funcional, usar a la defensiva

public Optional<Service> getRefrigertorControl() {
      Service s = new  RefrigeratorService();
       //...
      return Optional.ofNullable(s);
   }

Como ve, Optional.ofNullable()proporciona una manera fácil de obtener la referencia envuelta. Hay otras formas de obtener la referencia de Opcional, ya sea Optional.empty()& Optional.of(). Uno para devolver un objeto vacío en lugar de volver a sintonizar nulo y el otro para envolver un objeto no anulable, respectivamente.

¿CUÁNTO EXACTAMENTE LO AYUDA A EVITAR UNA COMPROBACIÓN NULA?

Una vez que haya envuelto un objeto de referencia, Opcional proporciona muchos métodos útiles para invocar métodos en una referencia envuelta sin NPE.

Optional ref = homeServices.getRefrigertorControl();
ref.ifPresent(HomeServices::switchItOn);

Optional.ifPresent invoca al Consumidor dado con una referencia si no es un valor nulo. De lo contrario, no hace nada.

@FunctionalInterface
public interface Consumer<T>

Representa una operación que acepta un solo argumento de entrada y no devuelve ningún resultado. A diferencia de la mayoría de las otras interfaces funcionales, se espera que el Consumidor opere a través de efectos secundarios. Es tan limpio y fácil de entender. En el ejemplo de código anterior, HomeService.switchOn(Service)se invoca si la referencia de retención Opcional no es nula.

Usamos el operador ternario muy a menudo para verificar la condición nula y devolver un valor alternativo o valor predeterminado. Opcional proporciona otra forma de manejar la misma condición sin marcar nulo. Optional.orElse (defaultObj) devuelve defaultObj si el Opcional tiene un valor nulo. Vamos a usar esto en nuestro código de muestra:

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

Ahora HomeServices.get () hace lo mismo, pero de una mejor manera. Comprueba si el servicio ya está inicializado o no. Si es así, devuelva lo mismo o cree un nuevo servicio nuevo. Opcional <T> .orElse (T) ayuda a devolver un valor predeterminado.

Finalmente, aquí está nuestro NPE y nuestro código nulo de verificación sin cargo:

import java.util.Optional;
public class HomeServices {
    private static final int NOW = 0;
    private static Optional<HomeServices> service;

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

public Optional<Service> getRefrigertorControl() {
    Service s = new  RefrigeratorService();
    //...
    return Optional.ofNullable(s);
}

public static void main(String[] args) {
    /* Get Home Services handle */
    Optional<HomeServices> homeServices = HomeServices.get();
    if(homeServices != null) {
        Optional<Service> refrigertorControl = homeServices.get().getRefrigertorControl();
        refrigertorControl.ifPresent(HomeServices::switchItOn);
    }
}

public static void switchItOn(Service s){
         //...
    }
}

La publicación completa es NPE, así como el código nulo de verificación sin cargo ... ¿En serio? .




He intentado el NullObjectPatternpero para mí no siempre es la mejor manera de ir. Hay ocasiones en que una "no acción" no es apropiada.

NullPointerExceptiones una excepción de Runtime que significa que es culpa de los desarrolladores y con suficiente experiencia le dice exactamente dónde está el error.

Ahora a la respuesta:

Intente hacer que todos sus atributos y sus accesores sean lo más privados posible o evite exponerlos a los clientes. Por supuesto, puede tener los valores de argumento en el constructor, pero al reducir el alcance, no permite que la clase cliente pase un valor no válido. Si necesita modificar los valores, siempre puede crear uno nuevo object. Verifica los valores en el constructor solo una vez y en el resto de los métodos puede estar casi seguro de que los valores no son nulos.

Por supuesto, la experiencia es la mejor manera de entender y aplicar esta sugerencia.

¡Byte!




¿Puedo contestarlo más generalmente?

Por lo general, nos enfrentamos a este problema cuando los métodos obtienen los parámetros de la forma que no esperábamos (la mala llamada es un error del programador). Por ejemplo: esperas obtener un objeto, en vez de eso obtienes un nulo. Usted espera obtener una Cadena con al menos un carácter, en lugar de obtener una Cadena vacía ...

Así que no hay diferencia entre:

if(object == null){
   //you called my method badly!

}

o

if(str.length() == 0){
   //you called my method badly again!
}

Ambos quieren asegurarse de que recibimos parámetros válidos, antes de realizar cualquier otra función.

Como se mencionó en algunas otras respuestas, para evitar los problemas anteriores, puede seguir el patrón Diseño por contrato . Por favor, consulte http://en.wikipedia.org/wiki/Design_by_contract .

Para implementar este patrón en java, puede usar anotaciones de java principales como javax.annotation.NotNull o usar bibliotecas más sofisticadas como Hibernate Validator .

Solo una muestra:

getCustomerAccounts(@NotEmpty String customerId,@Size(min = 1) String accountType)

Ahora puede desarrollar de forma segura la función principal de su método sin necesidad de verificar los parámetros de entrada, protegen sus métodos de parámetros inesperados.

Puede ir un paso más allá y asegurarse de que solo se puedan crear pojos válidos en su aplicación. (Muestra del sitio del validador de hibernación)

public class Car {

   @NotNull
   private String manufacturer;

   @NotNull
   @Size(min = 2, max = 14)
   private String licensePlate;

   @Min(2)
   private int seatCount;

   // ...
}



  1. Nunca inicialice variables a nulo.
  2. Si (1) no es posible, inicialice todas las colecciones y matrices a colecciones / matrices vacías.

Haciendo esto en tu propio código, puedes evitar! = Cheques nulos.

La mayoría de las veces, los controles nulos parecen proteger los bucles de las colecciones o los arreglos, así que simplemente inicialícelos, no necesitará ningún control nulo.

// Bad
ArrayList<String> lemmings;
String[] names;

void checkLemmings() {
    if (lemmings != null) for(lemming: lemmings) {
        // do something
    }
}



// Good
ArrayList<String> lemmings = new ArrayList<String>();
String[] names = {};

void checkLemmings() {
    for(lemming: lemmings) {
        // do something
    }
}

Hay una pequeña sobrecarga en esto, pero vale la pena por un código más limpio y menos NullPointerExceptions.




public static <T> T ifNull(T toCheck, T ifNull) {
    if (toCheck == null) {
           return ifNull;
    }
    return toCheck;
}



Related