1. Información general
Generalmente, las variables, referencias y colecciones nulas son difíciles de manejar en código Java. No solo son difíciles de identificar, sino que también son complejos de tratar.
De hecho, cualquier error al tratar con null no se puede identificar en tiempo de compilación y da como resultado una NullPointerException en tiempo de ejecución.
En este tutorial, veremos la necesidad de verificar nulos en Java y varias alternativas que nos ayudan a evitar verificaciones nulas en nuestro código.
2. ¿Qué es NullPointerException?
De acuerdo con Javadoc para NullPointerException , se lanza cuando una aplicación intenta usar null en un caso donde se requiere un objeto, como:
- Llamar a un método de instancia de un objeto nulo
- Acceder o modificar un campo de un objeto nulo
- Tomando la longitud de nulo como si fuera una matriz
- Acceder o modificar las ranuras de nulo como si fuera una matriz
- Lanzar null como si fuera un valor Throwable
Veamos rápidamente algunos ejemplos del código Java que causan esta excepción:
public void doSomething() { String result = doSomethingElse(); if (result.equalsIgnoreCase("Success")) // success } } private String doSomethingElse() { return null; }Aquí, intentamos invocar una llamada de método para una referencia nula . Esto resultaría en una NullPointerException.
Otro ejemplo común es si intentamos acceder a una matriz nula :
public static void main(String[] args) { findMax(null); } private static void findMax(int[] arr) { int max = arr[0]; //check other elements in loop }Esto provoca una NullPointerException en la línea 6.
Por lo tanto, acceder a cualquier campo, método o índice de un objeto nulo provoca una NullPointerException , como se puede ver en los ejemplos anteriores.
Una forma común de evitar la NullPointerException es verificar si hay nulo :
public void doSomething() { String result = doSomethingElse(); if (result != null && result.equalsIgnoreCase("Success")) { // success } else // failure } private String doSomethingElse() { return null; }En el mundo real, a los programadores les resulta difícil identificar qué objetos pueden ser nulos. Una estrategia agresivamente segura podría ser verificar nulo para cada objeto. Sin embargo, esto provoca muchas comprobaciones nulas redundantes y hace que nuestro código sea menos legible.
En las próximas secciones, veremos algunas de las alternativas en Java que evitan dicha redundancia.
3. Manejo de nulos a través del contrato API
Como se discutió en la última sección, el acceso a métodos o variables de objetos nulos causa una NullPointerException. También discutimos que poner una verificación nula en un objeto antes de acceder a él elimina la posibilidad de NullPointerException.
Sin embargo, a menudo hay API que pueden manejar valores nulos . Por ejemplo:
public void print(Object param) { System.out.println("Printing " + param); } public Object process() throws Exception { Object result = doSomething(); if (result == null) { throw new Exception("Processing fail. Got a null response"); } else { return result; } }La llamada al método print () simplemente imprimiría "nulo" pero no lanzaría una excepción. De manera similar, process () nunca devolvería null en su respuesta. Más bien lanza una excepción.
Entonces, para un código de cliente que accede a las API anteriores, no es necesario realizar una verificación nula .
Sin embargo, dichas API deben hacerlo explícito en su contrato. Un lugar común para que las API publiquen dicho contrato es JavaDoc .
Sin embargo, esto no da una indicación clara del contrato de API y, por lo tanto, depende de los desarrolladores del código del cliente para garantizar su cumplimiento.
En la siguiente sección, veremos cómo algunos IDE y otras herramientas de desarrollo ayudan a los desarrolladores con esto.
4. Automatización de contratos de API
4.1. Usar análisis de código estático
Las herramientas de análisis de código estático ayudan a mejorar mucho la calidad del código. Y algunas de estas herramientas también permiten a los desarrolladores mantener el contrato nulo . Un ejemplo es FindBugs.
FindBugs ayuda a administrar el contrato nulo a través de las anotaciones @Nullable y @NonNull . Podemos usar estas anotaciones sobre cualquier método, campo, variable local o parámetro. Esto hace que sea explícito para el código del cliente si el tipo anotado puede ser nulo o no. Veamos un ejemplo:
public void accept(@Nonnull Object param) { System.out.println(param.toString()); }Aquí, @NonNull deja en claro que el argumento no puede ser nulo. Si el código del cliente llama a este método sin verificar si el argumento es nulo, FindBugs generaría una advertencia en el momento de la compilación.
4.2. Uso de la compatibilidad con IDE
Los desarrolladores generalmente confían en los IDE para escribir código Java. Y características como la finalización de código inteligente y advertencias útiles, como cuando una variable puede no haber sido asignada, ciertamente ayudan en gran medida.
Algunos IDE también permiten a los desarrolladores administrar contratos de API y, por lo tanto, eliminan la necesidad de una herramienta de análisis de código estático. IntelliJ IDEA proporciona las anotaciones @NonNull y @Nullable . Para agregar el soporte para estas anotaciones en IntelliJ, debemos agregar la siguiente dependencia de Maven:
org.jetbrains annotations 16.0.2 Ahora, IntelliJ generará una advertencia si falta la verificación nula , como en nuestro último ejemplo.
IntelliJ también proporciona una anotación de contrato para manejar contratos API complejos.
5. Afirmaciones
Hasta ahora, solo hemos hablado de eliminar la necesidad de verificaciones nulas del código del cliente. Pero eso rara vez se aplica en aplicaciones del mundo real.
Ahora, supongamos que estamos trabajando con una API que no puede aceptar parámetros nulos o puede devolver una respuesta nula que debe ser manejada por el cliente . Esto presenta la necesidad de que verifiquemos los parámetros o la respuesta para un valor nulo .
Here, we can use Java Assertions instead of the traditional null check conditional statement:
public void accept(Object param){ assert param != null; doSomething(param); }In line 2, we check for a null parameter. If the assertions are enabled, this would result in an AssertionError.
Although it is a good way of asserting pre-conditions like non-null parameters, this approach has two major problems:
- Assertions are usually disabled in a JVM
- A false assertion results in an unchecked error that is irrecoverable
Hence, it is not recommended for programmers to use Assertions for checking conditions. In the following sections, we'll discuss other ways of handling null validations.
6. Avoiding Null Checks Through Coding Practices
6.1. Preconditions
It's usually a good practice to write code that fails early. Therefore, if an API accepts multiple parameters that aren't allowed to be null, it's better to check for every non-null parameter as a precondition of the API.
For example, let's look at two methods – one that fails early, and one that doesn't:
public void goodAccept(String one, String two, String three) { if (one == null || two == null || three == null) { throw new IllegalArgumentException(); } process(one); process(two); process(three); } public void badAccept(String one, String two, String three) { if (one == null) { throw new IllegalArgumentException(); } else { process(one); } if (two == null) { throw new IllegalArgumentException(); } else { process(two); } if (three == null) { throw new IllegalArgumentException(); } else { process(three); } }Clearly, we should prefer goodAccept() over badAccept().
As an alternative, we can also use Guava's Preconditions for validating API parameters.
6.2. Using Primitives Instead of Wrapper Classes
Since null is not an acceptable value for primitives like int, we should prefer them over their wrapper counterparts like Integer wherever possible.
Consider two implementations of a method that sums two integers:
public static int primitiveSum(int a, int b) { return a + b; } public static Integer wrapperSum(Integer a, Integer b) { return a + b; }Now, let's call these APIs in our client code:
int sum = primitiveSum(null, 2);This would result in a compile-time error since null is not a valid value for an int.
And when using the API with wrapper classes, we get a NullPointerException:
assertThrows(NullPointerException.class, () -> wrapperSum(null, 2));There are also other factors for using primitives over wrappers, as we covered in another tutorial, Java Primitives versus Objects.
6.3. Empty Collections
Occasionally, we need to return a collection as a response from a method. For such methods, we should always try to return an empty collection instead of null:
public List names() { if (userExists()) { return Stream.of(readName()).collect(Collectors.toList()); } else { return Collections.emptyList(); } }Hence, we've avoided the need for our client to perform a null check when calling this method.
7. Using Objects
Java 7 introduced the new Objects API. This API has several static utility methods that take away a lot of redundant code. Let's look at one such method, requireNonNull():
public void accept(Object param) { Objects.requireNonNull(param); // doSomething() }Now, let's test the accept() method:
assertThrows(NullPointerException.class, () -> accept(null));So, if null is passed as an argument, accept() throws a NullPointerException.
This class also has isNull() and nonNull() methods that can be used as predicates to check an object for null.
8. Using Optional
8.1. Using orElseThrow
Java 8 introduced a new Optional API in the language. This offers a better contract for handling optional values compared to null. Let's see how Optional takes away the need for null checks:
public Optional process(boolean processed) { String response = doSomething(processed); if (response == null) { return Optional.empty(); } return Optional.of(response); } private String doSomething(boolean processed) { if (processed) { return "passed"; } else { return null; } }By returning an Optional, as shown above, the process method makes it clear to the caller that the response can be empty and must be handled at compile time.
This notably takes away the need for any null checks in the client code. An empty response can be handled differently using the declarative style of the Optional API:
assertThrows(Exception.class, () -> process(false).orElseThrow(() -> new Exception()));Furthermore, it also provides a better contract to API developers to signify to the clients that an API can return an empty response.
Although we eliminated the need for a null check on the caller of this API, we used it to return an empty response. To avoid this, Optional provides an ofNullable method that returns an Optional with the specified value, or empty, if the value is null:
public Optional process(boolean processed) { String response = doSomething(processed); return Optional.ofNullable(response); }8.2. Using Optional with Collections
While dealing with empty collections, Optional comes in handy:
public String findFirst() { return getList().stream() .findFirst() .orElse(DEFAULT_VALUE); }This function is supposed to return the first item of a list. The Stream API's findFirst function will return an empty Optional when there is no data. Here, we have used orElse to provide a default value instead.
This allows us to handle either empty lists, or lists, which after we have used the Stream library's filter method, have no items to supply.
Alternatively, we can also allow the client to decide how to handle empty by returning Optional from this method:
public Optional findOptionalFirst() { return getList().stream() .findFirst(); }Therefore, if the result of getList is empty, this method will return an empty Optional to the client.
Using Optional with collections allows us to design APIs that are sure to return non-null values, thus avoiding explicit null checks on the client.
It's important to note here that this implementation relies on getList not returning null. However, as we discussed in the last section, it's often better to return an empty list rather than a null.
8.3. Combining Optionals
When we start making our functions return Optional we need a way to combine their results into a single value. Let's take our getList example from earlier. What if it were to return an Optional list, or were to be wrapped with a method that wrapped a null with Optional using ofNullable?
Our findFirst method wants to return an Optional first element of an Optional list:
public Optional optionalListFirst() { return getOptionalList() .flatMap(list -> list.stream().findFirst()); }By using the flatMap function on the Optional returned from getOptional we can unpack the result of an inner expression that returns Optional. Without flatMap, the result would be Optional
9. Libraries
9.1. Using Lombok
Lombok is a great library that reduces the amount of boilerplate code in our projects. It comes with a set of annotations that take the place of common parts of code we often write ourselves in Java applications, such as getters, setters, and toString(), to name a few.
Another of its annotations is @NonNull. So, if a project already uses Lombok to eliminate boilerplate code, @NonNull can replace the need for null checks.
Before we move on to see some examples, let's add a Maven dependency for Lombok:
org.projectlombok lombok 1.18.6 Now, we can use @NonNull wherever a null check is needed:
public void accept(@NonNull Object param){ System.out.println(param); }So, we simply annotated the object for which the null check would've been required, and Lombok generates the compiled class:
public void accept(@NonNull Object param) { if (param == null) { throw new NullPointerException("param"); } else { System.out.println(param); } }If param is null, this method throws a NullPointerException. The method must make this explicit in its contract, and the client code must handle the exception.
9.2. Using StringUtils
Generally, String validation includes a check for an empty value in addition to null value. Therefore, a common validation statement would be:
public void accept(String param){ if (null != param && !param.isEmpty()) System.out.println(param); }This quickly becomes redundant if we have to deal with a lot of String types. This is where StringUtils comes handy. Before we see this in action, let's add a Maven dependency for commons-lang3:
org.apache.commons commons-lang3 3.8.1 Let's now refactor the above code with StringUtils:
public void accept(String param) { if (StringUtils.isNotEmpty(param)) System.out.println(param); }So, we replaced our null or empty check with a static utility method isNotEmpty(). This API offers other powerful utility methods for handling common String functions.
10. Conclusión
En este artículo, analizamos las diversas razones de NullPointerException y por qué es difícil de identificar. Luego, vimos varias formas de evitar la redundancia en el código sobre la verificación de valores nulos con parámetros, tipos de retorno y otras variables.
Todos los ejemplos están disponibles en GitHub.