Java: Cómo comprobar si hay punteros nulos de manera eficiente

¿No estás optimizando un biiiiiiiiiiiiiiiiiiit demasiado prematuramente!?

Solo usaría el primero. Es claro y conciso.

Rara vez trabajo con Java, pero asumo que hay una manera de hacer que Assert solo opere en compilaciones de depuración, por lo que sería un no-no.

La tercera me da escalofríos, y creo que recurriría inmediatamente a la violencia si alguna vez la viera en código. No está claro lo que está haciendo.

No debe lanzar NullPointerException. Si quieres un NullPointerException, sólo dont comprobar el valor y será expulsada automáticamente cuando el parámetro es null y se intenta eliminar la referencia.

Echa un vistazo a las clases apache commons lang Validate y StringUtils.
Validate.notNull(variable) lanzará una excepción IllegalArgumentException si "variable" es null.
Validate.notEmpty(variable) lanzará una excepción IllegalArgumentException si "variable"está vacía (null o zero length".
Tal vez incluso mejor:
String trimmedValue = StringUtils.trimToEmpty(variable) garantizará que "trimmedValue" nunca sea nulo. Si " variable "es null," trimmedValue "será la cadena vacía ("").

Puede usar la clase de utilidad Objects.

public void method1(String arg) {
  Objects.requireNonNull(arg);
}

Véase http://docs.oracle.com/javase/7/docs/api/java/util/Objects.html#requireNonNull%28T%29

El primer método es mi preferencia porque transmite la mayor intención. A menudo hay atajos que se pueden tomar en la programación, pero mi opinión es que el código más corto no siempre es mejor código.

En mi opinión, hay tres problemas con el tercer método:

1. La intención no está clara para el lector casual.
2. Aunque tenga información sobre el número de línea, los números de línea cambian. En un sistema de producción real, saber que hubo un problema en SomeClass en la línea 100 no le da toda la información que necesita. También necesita conocer la revisión del archivo en cuestión y ser capaz de llegar a esa revisión. Con todo, un montón de problemas para lo que parece ser muy poco beneficio.
3. No está del todo claro por qué crees que la llamada a arg.getClass puede optimizarse. Es un método nativo. A menos que HotSpot esté codificado para tener un conocimiento específico del método para esta eventualidad exacta, probablemente dejará la llamada en paz ya que no puede saber acerca de los posibles efectos secundarios del código C que se llama.

Mi preferencia es usar #1 cada vez que siento que hay una necesidad de una comprobación nula. Tener el nombre de la variable en el mensaje de error es ideal para averiguar qué es exactamente lo que ha salido mal.

P.d. No creo que optimizar el número de tokens en el archivo fuente sea un criterio muy útil.

X = = null es súper rápido, y puede ser un par de relojes de CPU (incl. la predicción de rama que va a tener éxito). AssertNotNull estará en línea, así que no hay diferencia.

X. getClass() no debería ser más rápido que x==null incluso si usa trap. (razón: la x estará en algún registro y comprobar un registro vs un valor inmediato es rápido, la rama se va a predecir correctamente también)

En pocas palabras: a menos que hagas algo realmente raro, sería optimizado por el JVM.

La primera opción es la más fácil y también la más clara.

No es común en Java, pero en C y C++ donde el operador = se puede incluir en una expresión en la instrucción if y por lo tanto conducir a errores, a menudo se recomienda cambiar los lugares entre la variable y la constante de la siguiente manera:

if (NULL == variable) {
   ...
}

En lugar de:

if (variable == NULL) {
   ...
}

Previniendo errores del tipo:

if (variable = NULL) { // Assignment!
   ...
}

Si realiza el cambio, el compilador encontrará ese tipo de errores para usted.

Usaría el mecanismo integrado de Java assert.

assert arg != null;

La ventaja de esto sobre todos los otros métodos es que se puede desactivar.

Prefiero el método 4, 5 o 6, con #4 siendo aplicado a métodos API públicos y 5 / 6 para métodos internos, aunque #6 sería aplicado con más frecuencia a métodos públicos.

/**
 * Method 4.
 * @param arg A String that should have some method called upon it. Will be ignored if
 * null, empty or whitespace only.
 */
public void method4(String arg) {
   // commons stringutils
   if (StringUtils.isNotBlank(arg) {
       arg.trim();
   }
}

/**
 * Method 5.
 * @param arg A String that should have some method called upon it. Shouldn't be null.
 */
public void method5(String arg) {
   // Let NPE sort 'em out.
   arg.trim();
}

/**
 * Method 6.
 * @param arg A String that should have some method called upon it. Shouldn't be null.
 */
public void method5(String arg) {
   // use asserts, expect asserts to be enabled during dev-time, so that developers
   // that refuse to read the documentations get slapped on the wrist for still passing
   // null. Assert is a no-op if the -ae param is not passed to the jvm, so 0 overhead.

   assert arg != null : "Arg cannot be null"; // insert insult here.
   arg.trim();
}

La mejor solución para manejar nulls es no usar nulls. Wrap métodos de terceros o de bibliotecas que pueden devolver nulls con null guards, reemplazando el valor con algo que tiene sentido (como una cadena vacía) pero no hace nada cuando se usa. Lanzar NPE si un null realmente no debe ser pasado, especialmente en métodos setter donde el objeto pasado no se llama de inmediato.

No hay voto para este, pero uso una ligera variación de #2, como

erStr += nullCheck (varName, String errMsg); // returns formatted error message

Rationale: (1) I can loop over a bunch of arguments, (2) The nullCheck method is tucked away in a superclass and (3) at the end of the loop,

if (erStr.length() > 0)
    // Send out complete error message to client
else
    // do stuff with variables

En el método superclass, tu #3 se ve bien, pero no lanzaría una excepción (cuál es el punto, alguien tiene que manejarlo, y como un contenedor de servlet, tomcat lo ignorará, por lo que bien podría ser esto()) Saludos, - M. S.

Primer método. Nunca haría el segundo o el tercer método, no a menos que sean implementados eficientemente por la JVM subyacente. De lo contrario, esos dos son solo ejemplos principales de optimización prematura (con el tercero teniendo una posible penalización de rendimiento: no desea tratar y acceder a metadatos de clase en puntos de acceso generales.)

El problema con los NPE es que son cosas que cruzan muchos aspectos de la programación (y mis aspectos, me refiero a algo más profundo y más profundo que AOP). Es un problema de diseño del lenguaje (sin decir que el lenguaje es malo, pero que es una deficiencia fundamental... de cualquier lenguaje que permita punteros nulos o referencias.)

Como tal, es mejor tratar simplemente con él explícitamente como en el primer método. Todos los demás métodos son intentos (fallidos) de simplificar un modelo de operaciones, una complejidad inevitable que existe en el modelo de programación subyacente.

Es una bala que no podemos evitar morder. Tratar con él de forma explícita como en el caso general, que es menos doloroso el camino.

Aunque estoy de acuerdo con el consenso general de preferir evitar el hackeo getClass (), vale la pena señalar que, a partir de la versión 1.8.0_121 de OpenJDK, javac usará el hackeo getClass() para insertar comprobaciones nulas antes de crear expresiones lambda. Por ejemplo, considere:

public class NullCheck {
  public static void main(String[] args) {
    Object o = null;
    Runnable r = o::hashCode;
  }
}

Después de compilar esto con javac, puede usar javap para ver el bytecode ejecutando javap -c NullCheck. La salida es (en parte):

Compiled from "NullCheck.java"
public class NullCheck {
  public NullCheck();
    Code:
       0: aload_0
       1: invokespecial #1    // Method java/lang/Object."<init>":()V
       4: return

  public static void main(java.lang.String[]);
    Code:
       0: aconst_null
       1: astore_1
       2: aload_1
       3: dup
       4: invokevirtual #2    // Method java/lang/Object.getClass:()Ljava/lang/Class;
       7: pop
       8: invokedynamic #3, 0 // InvokeDynamic #0:run:(Ljava/lang/Object;)Ljava/lang/Runnable;
      13: astore_2
      14: return
}

El conjunto de instrucciones en las "líneas" 3, 4 y 7 están básicamente invocando o. getClass(), y descartando el resultado. Si ejecuta NullCheck, obtendrá una excepción NullPointerException lanzada desde la línea 4.

Si esto es algo que la gente de Java concluyó que era una optimización necesaria, o es solo un truco barato, no lo sé. Sin embargo, basado en el comentario de John Rose en https://bugs.openjdk.java.net/browse/JDK-8042127?focusedCommentId=13612451&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13612451, Sospecho que de hecho puede ser el caso que el hackeo getClass (), que produce una comprobación null implícita, puede ser ligeramente más performante que su contraparte explícita. Dicho esto, evitaría usarlo a menos que el benchmarking cuidadoso mostrara que hacía alguna diferencia apreciable.

(Curiosamente, el Compilador de Eclipse Para Java (ECJ) hace no incluir esta comprobación nula, y ejecutar NullCheck como compilado por ECJ no arrojará un n NPE.)

Creo que el cuarto y más útil patrón es no hacer nada. Su código lanzará NullPointerException u otra excepción un par de líneas más tarde (si null es un valor ilegal) y funcionará bien si null está bien en este contexto.

Creo que debe realizar una comprobación nula solo si tiene algo que ver con ella. La comprobación para lanzar la excepción es irrelevante en la mayoría de los casos. Simplemente no olvides mencionar en javadoc si el parámetro puede ser null.