Evitar != null declaraciones

https://stackoverflow.com/questions/271526

06-07-2019
|

Pregunta

Yo uso object != null mucho para evitar NullPointerException.

Hay una buena alternativa a esto?

Por ejemplo:

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

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

Tenga en cuenta que el aceptado la respuesta puede estar fuera de fecha, consulte https://stackoverflow.com/a/2386013/12943 para un método más reciente.

Solución

Esto para mí suena como un problema razonablemente común que los desarrolladores junior a intermedios tienden a enfrentar en algún momento: o no saben o no confían en los contratos en los que están participando y sobreprotegen defensivamente los nulos. Además, cuando escriben su propio código, tienden a confiar en los valores nulos devueltos para indicar algo que requiere que la persona que llama compruebe los valores nulos.

Para decirlo de otra manera, hay dos casos en los que aparece la comprobación nula:

Donde nulo es una respuesta válida en términos del contrato; y
Donde no es una respuesta válida.

(2) es fácil. Utilice assert declaraciones (aserciones) o permita la falla (por ejemplo, NullPointerException ). Las aserciones son una característica de Java altamente infrautilizada que se agregó en 1.4. La sintaxis es:

assert <condition>

assert <condition> : <object>

donde <condition> es una expresión booleana y <object> es un objeto cuya salida del método toString() se incluirá en el error.

Una instrucción Error arroja un AssertionError (-ea) si la condición no es verdadera. Por defecto, Java ignora las aserciones. Puede habilitar las aserciones pasando la opción <=> a la JVM. Puede habilitar y deshabilitar aserciones para clases y paquetes individuales. Esto significa que puede validar el código con las aserciones durante el desarrollo y las pruebas, y deshabilitarlas en un entorno de producción, aunque mis pruebas casi no han demostrado impacto en el rendimiento de las aserciones.

No usar aserciones en este caso está bien porque el código simplemente fallará, que es lo que sucederá si usa aserciones. La única diferencia es que con las afirmaciones puede ocurrir antes, de una manera más significativa y posiblemente con información adicional, lo que puede ayudarlo a descubrir por qué sucedió si no lo esperaba.

(1) es un poco más difícil. Si no tienes control sobre el código al que estás llamando, entonces estás atascado. Si nulo es una respuesta válida, debe verificarlo.

Sin embargo, si es el código lo que controlas (y este es a menudo el caso), entonces es una historia diferente. Evite usar nulos como respuesta. Con métodos que devuelven colecciones, es fácil: devolver colecciones vacías (o matrices) en lugar de nulos casi todo el tiempo.

Con no colecciones puede ser más difícil. Considere esto como un ejemplo: si tiene estas interfaces:

public interface Action {
  void doSomething();
}

public interface Parser {
  Action findAction(String userInput);
}

donde Parser toma datos sin procesar del usuario y encuentra algo que hacer, tal vez si está implementando una interfaz de línea de comando para algo. Ahora puede hacer que el contrato que devuelve sea nulo si no hay una acción adecuada. Eso lleva a la comprobación nula de la que estás hablando.

Una solución alternativa es nunca devolver nulo y en su lugar usar el Patrón de objeto nulo :

public class MyParser implements Parser {
  private static Action DO_NOTHING = new Action() {
    public void doSomething() { /* do nothing */ }
  };

  public Action findAction(String userInput) {
    // ...
    if ( /* we can't find any actions */ ) {
      return DO_NOTHING;
    }
  }
}

Comparar:

Parser parser = ParserFactory.getParser();
if (parser == null) {
  // now what?
  // this would be an example of where null isn't (or shouldn't be) a valid response
}
Action action = parser.findAction(someInput);
if (action == null) {
  // do nothing
} else {
  action.doSomething();
}

ParserFactory.getParser().findAction(someInput).doSomething();

que es un diseño mucho mejor porque conduce a un código más conciso.

Dicho esto, tal vez sea completamente apropiado que el método findAction () arroje una excepción con un mensaje de error significativo, especialmente en este caso en el que confía en la entrada del usuario. Sería mucho mejor para el método findAction lanzar una excepción que para que el método de llamada explote con una NullPointerException simple sin explicación.

try {
    ParserFactory.getParser().findAction(someInput).doSomething();
} catch(ActionNotFoundException anfe) {
    userConsole.err(anfe.getMessage());
}

O si cree que el mecanismo de prueba / captura es demasiado feo, en lugar de no hacer nada, su acción predeterminada debería proporcionar comentarios al usuario.

public Action findAction(final String userInput) {
    /* Code to return requested Action if found */
    return new Action() {
        public void doSomething() {
            userConsole.err("Action not found: " + userInput);
        }
    }
}

Otros consejos

Si usted utiliza (o de planificación de uso) de un IDE de Java como JetBrains IntelliJ IDEA, Eclipse o Netbeans o una herramienta como findbugs, a continuación, puede utilizar las anotaciones para resolver este problema.

Básicamente, tienes @Nullable y @NotNull.

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

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

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

El segundo ejemplo no compile (en IntelliJ IDEA).

Cuando se utiliza la primera helloWorld() función en otro trozo de código:

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

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

Mediante el parámetro

void someMethod(@NotNull someParameter) { }

si usted escribe algo como:

someMethod(null);

Esto no compilará.

El último ejemplo de uso de @Nullable

@Nullable iWantToDestroyEverything() { return null; }

Haciendo esto

iWantToDestroyEverything().something();

Y usted puede estar seguro de que esto no ocurra.:)

Es una buena manera de dejar que el compilador de verificación algo más de lo que lo hace normalmente y para hacer cumplir sus contratos a ser más fuerte.Lamentablemente, esto no es apoyado por todos los compiladores.

En IntelliJ IDEA 10.5 y, se añade soporte para cualquier otro @Nullable @NotNull implementaciones.

Ver blog Más flexible y configurable @aceptan valores null/@NotNull anotaciones.

Si no se permiten valores nulos

Si su método se llama externamente, comience con algo como esto:

public void method(Object object) {
  if (object == null) {
    throw new IllegalArgumentException("...");
  }

Entonces, en el resto de ese método, sabrás que object no es nulo.

Si es un método interno (no forma parte de una API), solo documente que no puede ser nulo, y eso es todo.

Ejemplo:

public String getFirst3Chars(String text) {
  return text.subString(0, 3);
}

Sin embargo, si su método simplemente pasa el valor y el siguiente método lo pasa, etc., podría ser problemático. En ese caso, es posible que desee comprobar el argumento como arriba.

Si se permite nulo

Esto realmente depende. Si encuentro que a menudo hago algo como esto:

if (object == null) {
  // something
} else {
  // something else
}

Entonces me ramifico y hago dos cosas completamente diferentes. No hay un fragmento de código feo, porque realmente necesito hacer dos cosas diferentes dependiendo de los datos. Por ejemplo, ¿debería trabajar en la entrada o debo calcular un buen valor predeterminado?

En realidad es raro que use el idioma " if (object != null && ... " ;.

Puede ser más fácil darle ejemplos, si muestra ejemplos de dónde usa habitualmente el idioma.

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 sobre la mesa para Java 7 agregar " manejo nulo-seguro " & # 8212; una sintaxis optimizada para 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 desreferenciar el identificador izquierdo si no es nulo; de lo contrario, evalúe el resto de la expresión como null. Algunas personas, como el miembro de Java Posse Dick Wall y el los votantes de Devoxx realmente aman esta propuesta, pero también hay oposición, alegando que en realidad fomentará un mayor uso de <=> como valor centinela.

Actualización: Un La propuesta oficial para un operador nulo-seguro en Java 7 se ha presentado en Project Coin. La sintaxis es un poco diferente al ejemplo anterior, pero es la misma noción.

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

Si los valores no definidos no están permitidos:

Puede configurar el IDE para advertirle sobre posibles null eliminar.E. g.en Eclipse, ver Preferencias > Java > Compilador > Errores/Advertencias/Null análisis.

Si los valores no definidos están permitidos:

Si desea definir una nueva API, donde los valores no definidos sentido, el uso de la Opción De Patrón (pueden ser familiares de los lenguajes funcionales).Tiene las siguientes ventajas:

Se indica explícitamente en el API ya sea de entrada o de salida existe o no existe.
El compilador obliga a manejar el "indefinido" caso.
La opción es una monada, así que no hay necesidad de detallado comprobación de nulos, simplemente utiliza el mapa/foreach/getOrElse o similar combinador de utilizar de forma segura el valor (ejemplo).

Java 8 tiene un built-in Optional clase (recomendado);para versiones anteriores, hay biblioteca alternativas, por ejemplo La guayaba's Optional o FunctionalJava's Option.Pero al igual que muchos funcional-patrones de estilo, usando la Opción en Java (hasta 8) el resultado es bastante repetitivo, lo que puede reducir el uso de menos detallado de la JVM idioma, por ejemplo,Scala o Xtend.

Si usted tiene que tratar con una API que puede devolver valores nulos, no se puede hacer mucho en Java.Xtend y Groovy tiene la Elvis operador ?: y el null-seguro de eliminar operador ?., pero ten en cuenta que este devuelve null en caso de una referencia nula, por lo que sólo es "aplaza" el manejo adecuado de null.

Solo para esta situación -

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

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

resultará en un NullPointerException si foo no existe.

Puede evitar eso si compara sus String s así:

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

Con Java 8 viene la nueva clase java.util.Optional que podría resolver parte del problema. Al menos se puede decir que mejora la legibilidad del código y, en el caso de las API públicas, hace que el contrato de la API sea más claro para el desarrollador del cliente.

Funcionan así:

Se crea un objeto opcional para un tipo dado (Fruit) como el tipo de retorno de un método. Puede estar vacío o contener un objeto fruits:

public static Optional<Fruit> find(String name, List<Fruit> fruits) {
   for (Fruit fruit : fruits) {
      if (fruit.getName().equals(name)) {
         return Optional.of(fruit);
      }
   }
   return Optional.empty();
}

Ahora mire este código donde buscamos una lista de map() (orElse()) para una instancia de Fruit determinada:

Optional<Fruit> found = find("lemon", fruits);
if (found.isPresent()) {
   Fruit fruit = found.get();
   String name = fruit.getName();
}

Puede usar el operador Optional para realizar un cálculo en un objeto opcional o extraer un valor de este. null le permite proporcionar una reserva para los valores faltantes.

String nameOrNull = find("lemon", fruits)
    .map(f -> f.getName())
    .orElse("empty-name");

Por supuesto, la verificación del valor nulo / vacío sigue siendo necesaria, pero al menos el desarrollador es consciente de que el valor puede estar vacío y el riesgo de olvidar verificar es limitado.

En una API creada desde cero utilizando orElse cuando un valor de retorno puede estar vacío, y devolviendo un objeto plano solo cuando no puede ser ifPresent (convención), el código del cliente puede abandonar las verificaciones nulas en valores de retorno de objetos simples ...

Por supuesto, NullPointerException también podría usarse como argumento de método, quizás una mejor manera de indicar argumentos opcionales que 5 o 10 métodos de sobrecarga en algunos casos.

<=> ofrece otros métodos convenientes, como <=> que permiten el uso de un valor predeterminado y <=> que funciona con expresiones lambda .

Los invito a leer este artículo (mi fuente principal para escribir esta respuesta) en el que la problemática <=> (y en general el puntero nulo) así como la solución (parcial) presentada por <=> están bien explicadas: Objetos opcionales de Java .

Dependiendo del tipo de objetos que esté verificando, puede usar algunas de las clases en los comunes de apache como: apache commons lang 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 hacen una manipulación segura nula.

Aquí sigue un ejemplo de cómo puede usar la validación nula en JAVA cuando incluye la biblioteca 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");

Si considera que un objeto no debe ser nulo (o es un error) use una afirmación.
Si su método no acepta parámetros nulos, dígalo en el javadoc y use una afirmación.

Debe verificar el objeto! = nulo solo si desea manejar el caso donde el objeto puede ser nulo ...

Existe una propuesta para agregar nuevas anotaciones en Java7 para ayudar con los parámetros nulos / no nulos: http://tech.puredanger.com/java7/#jsr308

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

El marco de colecciones de Google ofrece una forma buena y elegante de lograr la verificación nula.

Hay un método en una clase de biblioteca como este:

static <T> T checkNotNull(T e) {
   if (e == null) {
      throw new NullPointerException();
   }
   return e;
}

Y el uso es (con import static):

...
void foo(int a, Person p) {
   if (checkNotNull(p).getAge() > a) {
      ...
   }
   else {
      ...
   }
}
...

O en tu ejemplo:

checkNotNull(someobject).doCalc();

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 sabe que b nunca puede ser nulo, simplemente puede intercambiarlo. Es más útil para iguales: En lugar de foo.equals("bar"); mejor hacerlo "bar".equals(foo);.

En lugar del patrón de objeto nulo, que tiene sus usos, puede considerar situaciones en las que el objeto nulo es un error.

Cuando se produce la excepción, examine el seguimiento de la pila y resuelva el error.

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

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

El método es más útil para comprobación justo antes de una tarea 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

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

Null is not a 'problem'. It is an integral part of a complete modeling tool set. Software aims to model the complexity of the world and null bears its burden. Null indicates 'No data' or 'Unknown' in Java and the like. So it is appropriate to use nulls for these purposes. I don't prefer the 'Null object' pattern; I think it rise the 'who will guard the guardians' problem.
If you ask me what is the name of my girlfriend I'll tell you that I have no girlfriend. In the Java language I'll return null. An alternative would be to throw meaningful exception to indicate some problem that can't be (or don't want to be) solved right there and delegate it somewhere higher in the stack to retry or report data access error to the user.

For an 'unknown question' give 'unknown answer'. (Be null-safe where this is correct from business point of view) Checking arguments for null once inside a method before usage relieves multiple callers from checking them before a call.
```
public Photo getPhotoOfThePerson(Person person) {
    if (person == null)
        return null;
    // Grabbing some resources or intensive calculation
    // using person object anyhow.
}
```
Previous leads to normal logic flow to get no photo of a non-existent girlfriend from my photo library.
```
getPhotoOfThePerson(me.getGirlfriend())
```
And it fits with new coming Java API (looking forward)
```
getPhotoByName(me.getGirlfriend()?.getName())
```
While it is rather 'normal business flow' not to find photo stored into the DB for some person, I used to use pairs like below for some other cases
```
public static MyEnum parseMyEnum(String value); // throws IllegalArgumentException
public static MyEnum parseMyEnumOrNull(String value);
```
And don't loathe to type <alt> + <shift> + <j> (generate javadoc in Eclipse) and write three additional words for you public API. This will be more than enough for all but those who don't read documentation.
```
/**
 * @return photo or null
 */
```
or
```
/**
 * @return photo, never null
 */
```
This is rather theoretical case and in most cases you should prefer java null safe API (in case it will be released in another 10 years), but NullPointerException is subclass of an Exception. Thus it is a form of Throwable that indicates conditions that a reasonable application might want to catch (javadoc)! To use the first most advantage of exceptions and separate error-handling code from 'regular' code (according to creators of Java) it is appropriate, as for me, to catch NullPointerException.
```
public Photo getGirlfriendPhoto() {
    try {
        return appContext.getPhotoDataSource().getPhotoByName(me.getGirlfriend().getName());
    } catch (NullPointerException e) {
        return null;
    }
}
```
Questions could arise:

Q. What if getPhotoDataSource() returns null?
A. It is up to business logic. If I fail to find a photo album I'll show you no photos. What if appContext is not initialized? This method's business logic puts up with this. If the same logic should be more strict then throwing an exception it is part of the business logic and explicit check for null should be used (case 3). The new Java Null-safe API fits better here to specify selectively what implies and what does not imply to be initialized to be fail-fast in case of programmer errors.

Q. Redundant code could be executed and unnecessary resources could be grabbed.
A. It could take place if getPhotoByName() would try to open a database connection, create PreparedStatement and use the person name as an SQL parameter at last. The approach for an unknown question gives an unknown answer (case 1) works here. Before grabbing resources the method should check parameters and return 'unknown' result if needed.

Q. This approach has a performance penalty due to the try closure opening.
A. Software should be easy to understand and modify firstly. Only after this, one could think about performance, and only if needed! and where needed! (source), and many others).

PS. This approach will be as reasonable to use as the separate error-handling code from "regular" code principle is reasonable to use in some place. Consider the next example:
```
public SomeValue calculateSomeValueUsingSophisticatedLogic(Predicate predicate) {
    try {
        Result1 result1 = performSomeCalculation(predicate);
        Result2 result2 = performSomeOtherCalculation(result1.getSomeProperty());
        Result3 result3 = performThirdCalculation(result2.getSomeProperty());
        Result4 result4 = performLastCalculation(result3.getSomeProperty());
        return result4.getSomeProperty();
    } catch (NullPointerException e) {
        return null;
    }
}

public SomeValue calculateSomeValueUsingSophisticatedLogic(Predicate predicate) {
    SomeValue result = null;
    if (predicate != null) {
        Result1 result1 = performSomeCalculation(predicate);
        if (result1 != null && result1.getSomeProperty() != null) {
            Result2 result2 = performSomeOtherCalculation(result1.getSomeProperty());
            if (result2 != null && result2.getSomeProperty() != null) {
                Result3 result3 = performThirdCalculation(result2.getSomeProperty());
                if (result3 != null && result3.getSomeProperty() != null) {
                    Result4 result4 = performLastCalculation(result3.getSomeProperty());
                    if (result4 != null) {
                        result = result4.getSomeProperty();
                    }
                }
            }
        }
    }
    return result;
}
```
PPS. For those fast to downvote (and not so fast to read documentation) I would like to say that I've never caught a null-pointer exception (NPE) in my life. But this possibility was intentionally designed by the Java creators because NPE is a subclass of Exception. We have a precedent in Java history when ThreadDeath is an Error not because it is actually an application error, but solely because it was not intended to be caught! How much NPE fits to be an Error than ThreadDeath! But it is not.

Check for 'No data' only if business logic implies it.

public void updatePersonPhoneNumber(Long personId, String phoneNumber) {
    if (personId == null)
        return;
    DataSource dataSource = appContext.getStuffDataSource();
    Person person = dataSource.getPersonById(personId);
    if (person != null) {
        person.setPhoneNumber(phoneNumber);
        dataSource.updatePerson(person);
    } else {
        Person = new Person(personId);
        person.setPhoneNumber(phoneNumber);
        dataSource.insertPerson(person);
    }
}

and

public void updatePersonPhoneNumber(Long personId, String phoneNumber) {
    if (personId == null)
        return;
    DataSource dataSource = appContext.getStuffDataSource();
    Person person = dataSource.getPersonById(personId);
    if (person == null)
        throw new SomeReasonableUserException("What are you thinking about ???");
    person.setPhoneNumber(phoneNumber);
    dataSource.updatePerson(person);
}

If appContext or dataSource is not initialized unhandled runtime NullPointerException will kill current thread and will be processed by Thread.defaultUncaughtExceptionHandler (for you to define and use your favorite logger or other notification mechanizm). If not set, ThreadGroup#uncaughtException will print stacktrace to system err. One should monitor application error log and open Jira issue for each unhandled exception which in fact is application error. Programmer should fix bug somewhere in initialization stuff.

Ultimately, the only way to completely solve this problem is by using a different programming language:

In Objective-C, you can do the equivalent of invoking a method on nil, and absolutely nothing will happen. This makes most null checks unnecessary, but it can make errors much harder to diagnose.
In Nice, a Java-derived language, there are two versions of all types: a potentially-null version and a not-null version. You can only invoke methods on not-null types. Potentially-null types can be converted to not-null types through explicit checking for null. This makes it much easier to know where null checks are necessary and where they aren't.

Common "problem" in Java indeed.

First, my thoughts on this:

I consider that it is bad to "eat" something when NULL was passed where NULL isn't a valid value. If you're not exiting the method with some sort of error then it means nothing went wrong in your method which is not true. Then you probably return null in this case, and in the receiving method you again check for null, and it never ends, and you end up with "if != null", etc..

So, IMHO, null must be a critical error which prevents further execution (that is, where null is not a valid value).

The way I solve this problem is this:

First, I follow this convention:

All public methods / API always check its arguments for null
All private methods do not check for null since they are controlled methods (just let die with nullpointer exception in case it wasn't handled above)
The only other methods which do not check for null are utility methods. They are public, but if you call them for some reason, you know what parameters you pass. This is like trying to boil water in the kettle without providing water...

And finally, in the code, the first line of the public method goes like this:

ValidationUtils.getNullValidator().addParam(plans, "plans").addParam(persons, "persons").validate();

Note that addParam() returns self, so that you can add more parameters to check.

Method validate() will throw checked ValidationException if any of the parameters is null (checked or unchecked is more a design/taste issue, but my ValidationException is checked).

void validate() throws ValidationException;

The message will contain the following text if, for example, "plans" is null:

"Illegal argument value null is encountered for parameter [plans]"

As you can see, the second value in the addParam() method (string) is needed for the user message, because you cannot easily detect passed-in variable name, even with reflection (not subject of this post anyway...).

And yes, we know that beyond this line we will no longer encounter a null value so we just safely invoke methods on those objects.

This way, the code is clean, easy maintainable and readable.

Asking that question points out that you may be interested in error handling strategies. Your team's architect should decide how to work errors. There are several ways to do this:

allow the Exceptions to ripple through - catch them at the 'main loop' or in some other managing routine.
- check for error conditions and handle them appropriately

Sure do have a look at Aspect Oriented Programming, too - they have neat ways to insert if( o == null ) handleNull() into your bytecode.

In addition to using assert you can use the following:

if (someobject == null) {
    // Handle null here then move on.
}

This is slightly better than:

if (someobject != null) {
    .....
    .....



    .....
}

Just don't ever use null. Don't allow it.

In my classes, most fields and local variables have non-null default values, and I add contract statements (always-on asserts) everywhere in the code to make sure this is being enforced (since it's more succinct, and more expressive than letting it come up as an NPE and then having to resolve the line number, etc.).

Once I adopted this practice, I noticed that the problems seemed to fix themselves. You'd catch things much earlier in the development process just by accident and realize you had a weak spot.. and more importantly.. it helps encapsulate different modules' concerns, different modules can 'trust' each other, and no more littering the code with if = null else constructs!

This is defensive programming and results in much cleaner code in the long run. Always sanitize the data, e.g. here by enforcing rigid standards, and the problems go away.

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

The contracts are like mini-unit tests which are always running, even in production, and when things fail, you know why, rather than a random NPE you have to somehow figure out.

Guava, a very useful core library by Google, has a nice and useful API to avoid nulls. I find UsingAndAvoidingNullExplained very helpful.

As explained in the wiki:

Optional<T> is a way of replacing a nullable T reference with a non-null value. An Optional may either contain a non-null T reference (in which case we say the reference is "present"), or it may contain nothing (in which case we say the reference is "absent"). It is never said to "contain null."

Usage:

Optional<Integer> possible = Optional.of(5);
possible.isPresent(); // returns true
possible.get(); // returns 5

This is a very common problem for every Java developer. So there is official support in Java 8 to address these issues without cluttered code.

Java 8 has introduced java.util.Optional<T>. It is a container that may or may not hold a non-null value. Java 8 has given a safer way to handle an object whose value may be null in some of the cases. It is inspired from the ideas of Haskell and Scala.

In a nutshell, the Optional class includes methods to explicitly deal with the cases where a value is present or absent. However, the advantage compared to null references is that the Optional<T> class forces you to think about the case when the value is not present. As a consequence, you can prevent unintended null pointer exceptions.

In above example we have a home service factory that returns a handle to multiple appliances available in the home. But these services may or may not be available/functional; it means it may result in a NullPointerException. Instead of adding a null if condition before using any service, let's wrap it in to Optional<Service>.

WRAPPING TO OPTION<T>

Let's consider a method to get a reference of a service from a factory. Instead of returning the service reference, wrap it with Optional. It lets the API user know that the returned service may or may not available/functional, use defensively

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

As you see Optional.ofNullable() provides an easy way to get the reference wrapped. There are another ways to get the reference of Optional, either Optional.empty() & Optional.of(). One for returning an empty object instead of retuning null and the other to wrap a non-nullable object, respectively.

SO HOW EXACTLY IT HELPS TO AVOID A NULL CHECK?

Once you have wrapped a reference object, Optional provides many useful methods to invoke methods on a wrapped reference without NPE.

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

Optional.ifPresent invokes the given Consumer with a reference if it is a non-null value. Otherwise, it does nothing.

@FunctionalInterface
public interface Consumer<T>

Represents an operation that accepts a single input argument and returns no result. Unlike most other functional interfaces, Consumer is expected to operate via side-effects. It is so clean and easy to understand. In the above code example, HomeService.switchOn(Service) gets invoked if the Optional holding reference is non-null.

We use the ternary operator very often for checking null condition and return an alternative value or default value. Optional provides another way to handle the same condition without checking null. Optional.orElse(defaultObj) returns defaultObj if the Optional has a null value. Let's use this in our sample code:

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

Now HomeServices.get() does same thing, but in a better way. It checks whether the service is already initialized of not. If it is then return the same or create a new New service. Optional<T>.orElse(T) helps to return a default value.

Finally, here is our NPE as well as null check-free code:

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

The complete post is NPE as well as Null check-free code … Really?.

I like articles from Nat Pryce. Here are the links:

In the articles there is also a link to a Git repository for a Java Maybe Type which I find interesting, but I don't think it alone could decrease the checking code bloat. After doing some research on the Internet, I think != null code bloat could be decreased mainly by careful design.

I've tried the NullObjectPattern but for me is not always the best way to go. There are sometimes when a "no action" is not appropiate.

NullPointerException is a Runtime exception that means it's developers fault and with enough experience it tells you exactly where is the error.

Now to the answer:

Try to make all your attributes and its accessors as private as possible or avoid to expose them to the clients at all. You can have the argument values in the constructor of course, but by reducing the scope you don't let the client class pass an invalid value. If you need to modify the values, you can always create a new object. You check the values in the constructor only once and in the rest of the methods you can be almost sure that the values are not null.

Of course, experience is the better way to understand and apply this suggestion.

Byte!

Probably the best alternative for Java 8 or newer is to use the Optional class.

Optional stringToUse = Optional.of("optional is there");
stringToUse.ifPresent(System.out::println);

This is especially handy for long chains of possible null values. Example:

Optional<Integer> i = Optional.ofNullable(wsObject.getFoo())
    .map(f -> f.getBar())
    .map(b -> b.getBaz())
    .map(b -> b.getInt());

Example on how to throw exception on null:

Optional optionalCarNull = Optional.ofNullable(someNull);
optionalCarNull.orElseThrow(IllegalStateException::new);

Java 7 introduced the Objects.requireNonNull method which can be handy when something should be checked for non-nullness. Example:

String lowerVal = Objects.requireNonNull(someVar, "input cannot be null or empty").toLowerCase();

May I answer it more generally!

We usually face this issue when the methods get the parameters in the way we not expected (bad method call is programmer's fault). For example: you expect to get an object, instead you get a null. You expect to get an String with at least one character, instead you get an empty String ...

So there is no difference between:

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

}

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

They both want to make sure that we received valid parameters, before we do any other functions.

As mentioned in some other answers, to avoid above problems you can follow the Design by contract pattern. Please see http://en.wikipedia.org/wiki/Design_by_contract.

To implement this pattern in java, you can use core java annotations like javax.annotation.NotNull or use more sophisticated libraries like Hibernate Validator.

Just a sample:

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

Now you can safely develop the core function of your method without needing to check input parameters, they guard your methods from unexpected parameters.

You can go a step further and make sure that only valid pojos could be created in your application. (sample from hibernate validator site)

public class Car {

   @NotNull
   private String manufacturer;

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

   @Min(2)
   private int seatCount;

   // ...
}

I highly disregard answers that suggest using the null objects in every situation. This pattern may break the contract and bury problems deeper and deeper instead of solving them, not mentioning that used inappropriately will create another pile of boilerplate code that will require future maintenance.

In reality if something returned from a method can be null and the calling code has to make decision upon that, there should an earlier call that ensures the state.

Also keep in mind, that null object pattern will be memory hungry if used without care. For this - the instance of a NullObject should be shared between owners, and not be an unigue instance for each of these.

Also I would not recommend using this pattern where the type is meant to be a primitive type representation - like mathematical entities, that are not scalars: vectors, matrices, complex numbers and POD(Plain Old Data) objects, which are meant to hold state in form of Java built-in types. In the latter case you would end up calling getter methods with arbitrary results. For example what should a NullPerson.getName() method return?

It's worth considering such cases in order to avoid absurd results.

Never initialise variables to null.
If (1) is not possible, initialise all collections and arrays to empty collections/arrays.

Doing this in your own code and you can avoid != null checks.

Most of the time null checks seem to guard loops over collections or arrays, so just initialise them empty, you won't need any null checks.

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

There is a tiny overhead in this, but it's worth it for cleaner code and less NullPointerExceptions.

This is the most common error occurred for most of the developers.

We have number of ways to handle this.

Approach 1:

org.apache.commons.lang.Validate //using apache framework

notNull(Object object, String message)

Approach 2:

if(someObject!=null){ // simply checking against null
}

Approach 3:

@isNull @Nullable  // using annotation based validation

Approach 4:

// by writing static method and calling it across whereever we needed to check the validation

static <T> T isNull(someObject e){  
   if(e == null){
      throw new NullPointerException();
   }
   return e;
}

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

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow