IllegalArgumentException o NullPointerException para un parámetro null? [cerrado]

Debe usar IllegalArgumentException (IAE), no NullPointerException (NPE) por las siguientes razones:

Primero, el NPE JavaDoc enumera explícitamente los casos en los que NPE es apropiado. Observe que todos ellos son lanzados por el tiempo de ejecución cuando null se usa de manera inapropiada. En contraste, el IAE JavaDoc no podría ser más claro: "Lanzado para indicar que un método ha sido pasado un argumento ilegal o inapropiado."¡Sí, eres tú!

Segundo, cuando ves un NPE en un stack Trace, ¿qué asumes? Probablemente alguien desreferenció un null. Cuando ves IAE, asumes que la persona que llama del método en la parte superior de la pila pasa un valor ilegal. Una vez más, la última suposición es cierta, la primera es engañosa.

En tercer lugar, dado que IAE está claramente diseñado para validar parámetros, debe asumirlo como la opción predeterminada de excepción, así que ¿por qué elegiría NPE en su lugar? Ciertamente no para un comportamiento diferente do ¿realmente esperas llamar al código para coger NPE por separado de IAE y hacer algo diferente como resultado? ¿Está tratando de comunicar un mensaje de error más específico? Pero puede hacer eso en el texto del mensaje de excepción de todos modos, como debería para todos los demás parámetros incorrectos.

En cuarto lugar, todos los demás datos de parámetros incorrectos serán IAE, así que ¿por qué no ser consistentes? ¿Por qué es que un null ilegal es tan especial que merece una excepción separada de todos los otros tipos de argumentos ilegales?

Finalmente, acepto la argumento dado por otras respuestas que partes de la API de Java utilizan NPE de esta manera. Sin embargo, la API de Java es inconsistente con todo, desde tipos de excepción hasta convenciones de nombres, por lo que creo que copiar ciegamente (su parte favorita de) la API de Java no es un argumento lo suficientemente bueno como para superar estas otras consideraciones.

El estándar es lanzar la excepción NullPointerException. El generalmente infalible "Java Efectivo" discute esto brevemente en el Ítem 42 (primera edición), Ítem 60 (segunda edición), o Ítem 72 (tercera edición) "Favorezca el uso de excepciones estándar":

" Podría decirse, todo método erróneo invocaciones se reducen a un ilegal argumento o estado ilegal, pero otros las excepciones se utilizan de forma estándar para ciertos tipos de argumentos ilegales y estado. Si una persona que llama pasa null en algunos parámetro para el que los valores null están prohibidos, dicta la convención que NullPointerException ser lanzado en lugar de IllegalArgumentException."

Estaba a favor de lanzar IllegalArgumentException para parámetros nulos, hasta hoy, cuando noté el método java.util.Objects.requireNonNull en Java 7. Con ese método, en lugar de hacer:

if (param == null) {
    throw new IllegalArgumentException("param cannot be null.");
}

Puedes hacer:

Objects.requireNonNull(param);

Y lanzará un NullPointerException si el parámetro que pasa es null.

Dado que ese método está justo en el medio de java.util Tomo su existencia como una indicación bastante fuerte de que lanzar NullPointerException es "la forma Java de hacer las cosas".

Creo que estoy decidido en cualquier tasa.

Tenga en cuenta que los argumentos sobre la depuración dura son falsos porque, por supuesto, puede proporcionar un mensaje a NullPointerException diciendo qué era nulo y por qué no debería ser nulo. Al igual que con IllegalArgumentException.

Una ventaja añadida de NullPointerException es que, en código crítico de alto rendimiento, podría prescindir de una comprobación explícita de null (y un NullPointerException con un mensaje de error amigable), y simplemente confiar en el NullPointerException que obtendrá automáticamente cuando llame a un método en el parámetro null. Siempre que llama a un método rápidamente (es decir, falla rápido), entonces tienes esencialmente el mismo efecto, solo que no es tan fácil de usar para el desarrollador. La mayoría de las veces es probablemente mejor verificar explícitamente y lanzar con un mensaje útil para indicar qué parámetro era nulo, pero es bueno tener la opción de cambiar eso si el rendimiento dicta sin romper el contrato publicado del método/constructor.

Tiendo a seguir el diseño de bibliotecas JDK, especialmente Colecciones y Concurrencia (Joshua Bloch, Doug Lea, esos chicos saben cómo diseñar APIs sólidas). De todos modos, muchas API en el JDK lanzan pro-activamente NullPointerException.

Por ejemplo, el Javadoc para Map.containsKey establece:

@ lanza NullPointerException si la clave es null y este mapa no permite claves nulas (opcional).

Es perfectamente válido lanzar su propio NPE. La convención debe incluir el parámetro nombre que era null en el mensaje de la excepción.

El patrón dice:

public void someMethod(Object mustNotBeNull) {  
    if (mustNotBeNull == null) {  
        throw new NullPointerException("mustNotBeNull must not be null");  
    }  
}

Haga lo que haga, no permita que se establezca un valor malo y lance una excepción más tarde cuando otro código intente usarlo. Eso hace que la depuración sea una pesadilla. Siempre debe seguir el principio "fail-fast".

Voté el argumento de Jason Cohen porque estaba bien presentado. Déjame desmembrarlo paso a paso. ;-)

• El NPE JavaDoc explícitamente dice, "otros usos ilegales del objeto nulo". Si se limitara a situaciones en las que el tiempo de ejecución encuentra un null cuando no debería, todos estos casos podrían definirse de manera mucho más sucinta.

• No puedo evitarlo si asumes la cosa equivocada, pero asumiendo que la encapsulación se aplica correctamente, realmente no debería importarle o notar si un null fue desreferenciado inapropiadamente vs. si un método detectó un null inapropiado y disparó una excepción.

• Elegiría NPE sobre IAE por múltiples razones

  • Es más específico sobre la naturaleza de la operación ilegal
  • La lógica que por error permite valores nulos tiende a ser muy diferente de la lógica que por error permite valores ilegales. Por ejemplo, si estoy validando datos introducidos por un usuario, si obtengo un valor que es inaceptable, la fuente de ese error es con el usuario final de la aplicación. Si obtengo un null, es un error del programador.
  • Los valores no válidos pueden causar cosas como desbordamientos de pila, errores de memoria, excepciones de análisis, etc. De hecho, la mayoría de los errores generalmente se presentan, en algún momento, como un valor no válido en alguna llamada a método. Por esta razón veo IAE como realmente la MÁS GENERAL de todas las excepciones bajo RuntimeException.

• En Realidad, otros argumentos no válidos pueden dar lugar a todo tipo de excepciones. UnknownHostException, FileNotFoundException , una variedad de excepciones de errores de sintaxis, IndexOutOfBoundsException, fallos de autenticación, etc., sucesivamente.

En general, siento que NPE es muy difamado porque tradicionalmente se ha asociado con el código que no sigue el principio fail fast. Eso, además de la falla del JDK para llenar NPE con una cadena de mensaje realmente ha creado un fuerte sentimiento negativo que no está bien fundado. De hecho, la diferencia entre NPE e IAE desde una perspectiva de tiempo de ejecución es estrictamente el nombre. Desde esa perspectiva, cuanto más preciso sea con el nombre, más claridad le dará a la persona que llama.

Es una pregunta al estilo de la "Guerra Santa". En otras palabras, ambas alternativas son buenas, pero las personas tendrán sus preferencias que defenderán hasta la muerte.

Si es un método setter y null se le está pasando, creo que tendría más sentido lanzar un IllegalArgumentException. A NullPointerException parece tener más sentido en el caso de que usted está tratando de utilizar realmente el null.

Entonces, si lo estás usando y es null, NullPointer. Si se está pasando y es null, IllegalArgument.

Apache Commons Lang tiene un NullArgumentException que hace varias de las cosas discutidas aquí: extiende IllegalArgumentException y su único constructor toma el nombre del argumento que debería haber sido no nulo.

Mientras siento que lanzar algo así como un NullArgumentException o IllegalArgumentException describe con más precisión las circunstancias excepcionales, mis colegas y yo hemos decidido aplazar para Bloch el asesoramiento sobre el tema.

No podría estar más de acuerdo con lo que se está diciendo. Falla temprano, falla rápido. Muy buen mantra de excepción.

La pregunta sobre qué excepción lanzar es principalmente una cuestión de gusto personal. En mi mente, IllegalArgumentException parece más específico que usar un NPE, ya que me está diciendo que el problema era con un argumento que pasé al método y no con un valor que puede haber sido generado mientras realizaba el método.

Mis 2 Centavos

La práctica aceptada es usar la IllegalArgumentException( String message ) para declarar un parámetro como inválido y dar tantos detalles como sea posible... Por lo tanto, para decir que se encontró que un parámetro es nulo mientras que la excepción no es nula, haría algo como esto:

if( variable == null )
    throw new IllegalArgumentException("The object 'variable' cannot be null");

No tiene prácticamente ninguna razón para usar implícitamente la "NullPointerException". La excepción NullPointerException es una excepción lanzada por la máquina Virtual Java cuando intenta ejecutar código en referencia null (Como toString()).

En realidad, la cuestión de lanzar Ilegalargumentexception o NullPointerException es, en mi humilde opinión, solo una "guerra santa" para una minoría con una comprensión incompetente del manejo de excepciones en Java. En general, las reglas son simples, y de la siguiente manera:

• las violaciones de restricción de argumento deben indicarse lo más rápido posible (- >error rápido), para evitar estados ilegales que son mucho más difíciles de depurar
• en caso de un puntero nulo inválido por cualquier razón, lanzar NullPointerException
• en caso de un índice de array/colección ilegal, ArrayIndexOutOfBounds
• en caso de un array/tamaño de colección negativo, throw NegativeArraySizeException
• en caso de un argumento ilegal que no esté cubierto por lo anterior, y para el que no tenga otro tipo de excepción más específico, lance IllegalArgumentException como una papelera
• por otro lado, en caso de una violación de restricción DENTRO de un CAMPO que no se pudo evitar con rapidez fail por alguna razón válida, catch y rethrow como IllegalStateException o una excepción comprobada más específica. Nunca deje pasar el NullPointerException original, ArrayIndexOutOfBounds, etc en este caso!

Hay al menos tres razones muy buenas en contra del caso de mapear todo tipo de violaciones de restricción de argumento a Ilegalargumentexception, con la tercera probablemente siendo tan severa como para marcar el estilo de la práctica:

(1) Un programador no puede asumir con seguridad que todos los casos de violaciones de restricciones de argumento resultan en una excepción ilegal, porque la gran mayoría de las clases estándar usan esta excepción más bien como una papelera si no hay un tipo más específico de excepción disponible. Intentar mapear todos los casos de violaciones de restricciones de argumento a IllegalArgumentException en su API solo conduce a la frustración del programador usando sus clases, ya que las bibliotecas estándar siguen principalmente reglas diferentes que violan las suyas, y la mayoría de los usuarios de su API las usarán como ¡bueno!

(2) Mapear las excepciones en realidad resulta en un tipo diferente de anomalía, causada por herencia única: Todas las excepciones de Java son clases, y por lo tanto solo admiten herencia única. Por lo tanto, no hay manera de crear una excepción que sea realmente una excepción NullPointerException y una excepción IllegalArgumentException, ya que las subclases solo pueden heredar de una u otra. Lanzar una excepción IllegalArgumentException en caso de un argumento nulo, por lo tanto, hace que sea más difícil para los usuarios de API distinga entre problemas cada vez que un programa intenta corregir el problema mediante programación, por ejemplo, introduciendo valores predeterminados en una repetición de llamada.

(3) El mapeo en realidad crea el peligro de enmascaramiento de errores: Para mapear violaciones de restricciones de argumento en IllegalArgumentException, necesitará codificar un try-catch externo dentro de cada método que tenga argumentos restringidos. Sin embargo, simplemente la captura de RuntimeException en este bloque de captura está fuera de la cuestión, ya que los riesgos mapear RuntimeExceptions documentados lanzados por métodos libery utilizados dentro de la suya en IllegalArgumentException, incluso si no son causados por violaciones de restricciones de argumento. Por lo tanto, debe ser muy específico, pero incluso ese esfuerzo no lo protege del caso de que mapee accidentalmente una excepción de tiempo de ejecución indocumentada de otra API (es decir, un error) en una excepción de carga ilegal de su API. Incluso el mapeo más cuidadoso por lo tanto corre el riesgo de enmascarar errores de programación de otros fabricantes de bibliotecas como violaciones de restricción de argumento de los usuarios de su método, que es simplemente comportamiento hillareous!

Con la práctica estándar, por otro lado, las reglas permanecen simples, y las causas de excepción permanecen desenmascaradas y específicas. Para el método que llama, las reglas también son fáciles: - si se encuentra con una excepción de tiempo de ejecución documentada de cualquier tipo porque se pasó un valor ilegal, o bien repetir la llamada con un valor predeterminado (para esta excepciones específicas son necesarias), o corregir su código - si en el otro si encuentra una excepción de tiempo de ejecución que no está documentada para un conjunto dado de argumentos, envíe un informe de error a los creadores del método para asegurarse de que su código o su documentación se corrijan.

En general, un desarrollador debe nunca lanzar una excepción NullPointerException. Esta excepción es lanzada por el tiempo de ejecución cuando el código intenta desreferenciar una variable cuyo valor es null. Por lo tanto, si su método desea rechazar explícitamente null, en lugar de simplemente hacer que un valor null genere una NullPointerException, debe lanzar una IllegalArgumentException.

Lanzar una excepción que es exclusiva de los argumentos null (ya sea NullPointerException o un tipo personalizado) hace que las pruebas automatizadas null sean más confiables. Esta prueba automatizada se puede hacer con reflexión y un conjunto de valores por defecto, como en Guava ' s NullPointerTester. Por ejemplo, NullPointerTester intentaría llamar al siguiente método...

Foo(String string, List<?> list) {
  checkArgument(string.length() > 0);
  // missing null check for list!
  this.string = string;
  this.list = list;
}

...con dos listas de argumentos: "", null y null, ImmutableList.of(). Probaría que cada una de estas llamadas arroja el NullPointerException esperado. Para esta implementación, pasar una lista null no produce NullPointerException. Sin embargo, produce un IllegalArgumentException porque NullPointerTester utiliza una cadena predeterminada de "". Si NullPointerTester espera solo NullPointerException para los valores null, detecta el error. Si espera IllegalArgumentException, lo pierde.

Como una pregunta subjetiva esto debe cerrarse, pero como todavía está abierto:

Esto forma parte de la política interna utilizada en mi anterior lugar de trabajo y funcionó muy bien. Todo esto es de memoria, así que no puedo recordar la redacción exacta. Vale la pena señalar que no usaron excepciones verificadas, pero eso está más allá del alcance de la pregunta. Las excepciones no verificadas que sí utilizaron cayeron en 3 categorías principales.

NullPointerException: No lanzar intencionalmente. NPEs son para ser lanzado solo por la VM cuando desreferenciar una referencia nula. Hay que hacer todos los esfuerzos posibles para garantizar que nunca se lanzan. @Nullable y @NotNull deben usarse junto con herramientas de análisis de código para encontrar estos errores.

IllegalArgumentException: Lanzado cuando un argumento a una función no se ajusta a la documentación pública, de modo que el error se puede identificar y describir en términos de los argumentos pasados. La situación de la OP caería en esta categoría.

IllegalStateException: Lanzado cuando se llama a una función y sus argumentos son inesperados en el momento en que se pasan o incompatibles con el estado del objeto del que es miembro el método.

Por ejemplo, había dos versiones internas de la IndexOutOfBoundsException usadas en cosas que tenían una longitud. Una subclase de IllegalStateException, utilizada si el índice es mayor que la longitud. El otro una subclase de IllegalArgumentException, utilizado si el índice fue negativo. Esto se debe a que podría agregar más elementos al objeto y el argumento sería válido, mientras que un número negativo nunca es válido.

Como he dicho, este sistema funciona muy bien, y tomó alguien para explicar por qué la distinción está allí: "Dependiendo del tipo de error que es bastante sencillo para que usted pueda averiguar qué hacer. Incluso si en realidad no puede averiguar qué salió mal, puede averiguar dónde detectar ese error y crear una depuración adicional información."

NullPointerException: Maneja el caso nulo o coloca una aserción para que el NPE no sea lanzado. Si usted pone en una afirmación es solo uno de los otros dos tipos. Si es posible, continúe depurando como si la aserción estuviera allí en primer lugar.

IllegalArgumentException: tienes algo mal en tu sitio de llamadas. Si los valores que se pasan son de otra función, averigüe por qué está recibiendo un valor incorrecto. Si usted está pasando en uno de sus los argumentos propagan el error comprueba la pila de llamadas hasta que encuentre la función que no devuelve lo que espera.

IllegalStateException: No ha llamado a sus funciones en el orden correcto. Si está utilizando uno de sus argumentos, revíselos y lance una excepción ilegal que describa el problema. A continuación, puede propagar las mejillas contra la pila hasta que encuentre el problema.

De todos modos, su punto era que solo se puede copiar el IllegalArgumentAssertions hasta el pila. No hay manera de propagar los IllegalStateExceptions o NullPointerExceptions en la pila porque tenían algo que ver con su función.

Quería destacar argumentos nulos de otros argumentos ilegales, así que derivé una excepción de IAE llamada NullArgumentException. Sin necesidad de leer el mensaje de excepción, sé que se pasó un argumento null a un método y leyendo el mensaje, descubro qué argumento era null. Todavía capto la excepción NullArgumentException con un controlador IAE, pero en mis registros es donde puedo ver la diferencia rápidamente.

La dicotomía... ¿No se superponen? Solo las partes no superpuestas de un todo pueden hacer una dicotomía. Como yo lo veo:

throw new IllegalArgumentException(new NullPointerException(NULL_ARGUMENT_IN_METHOD_BAD_BOY_BAD));

Algunas colecciones asumen que null se rechaza usando NullPointerException en lugar de IllegalArgumentException. Por ejemplo, si compara un conjunto que contiene null con un conjunto que rechaza null, el primer conjunto llamará a containsAll en el otro y atrapará su NullPointerException but pero no IllegalArgumentException. (Estoy mirando la implementación de AbstractSet.equals.)

Se podría argumentar razonablemente que usar excepciones sin marcar de esta manera es un antipatrón, que comparar colecciones que contienen null con colecciones que no pueden contener null es un error probable que realmente debería producir una excepción, o que poner null en una colección es una mala idea. Sin embargo, a menos que estés dispuesto a decir que equals debe lanzar una excepción en tal caso, estás atascado recordando que NullPointerException se requiere en ciertas circunstancias pero no en otras. ("IAE antes de NPE excepto después de 'c'...")

NullPointerException lanzado al intentar acceder a un objeto con una variable de referencia cuyo valor actual es null

IllegalArgumentException lanzado cuando un método recibe un argumento con un formato diferente al que el método espera

De acuerdo con su escenario, IllegalArgumentException es la mejor opción, porque null no es un valor válido para su propiedad.

Idealmente las excepciones en tiempo de ejecución no deberían ser lanzadas. Se debe crear una excepción marcada (excepción de negocio) para su escenario. Porque si cualquiera de estas excepciones se lanza y se registra, malguía al desarrollador mientras revisaba los registros. En cambio, las excepciones comerciales no crean ese pánico y generalmente se ignoran al solucionar problemas de registros.

Las definiciones de los enlaces a las dos excepciones anteriores son IllegalArgumentException: Lanzado para indicar que un método ha sido pasado un argumento ilegal o inapropiado. NullPointerException: Lanzado cuando una aplicación intenta usar null en un caso donde se requiere un objeto.

La gran diferencia aquí es que se supone que se usa la excepción IllegalArgumentException cuando se comprueba que un argumento de un método es válido. NullPointerException se supone que se usa siempre que un objeto ser "usado" cuando es nulo.

Espero que eso ayude a poner los dos en perspectiva.

Si se trata de un "setter", o en algún lugar en el que estoy consiguiendo que un miembro lo use más tarde, tiendo a usar IllegalArgumentException.

Si es algo que voy a usar (dereference) ahora mismo en el método, lanzo una NullPointerException proactivamente. Me gusta esto mejor que dejar que el tiempo de ejecución lo haga, porque puedo proporcionar un mensaje útil (parece que el tiempo de ejecución también podría hacer esto, pero eso es una diatriba para otro día).

Si estoy sobreescribiendo un método, utilizo el método que se sobreescribe utilizar.

Debe lanzar una excepción IllegalArgumentException, ya que hará obvio para el programador que ha hecho algo inválido. Los desarrolladores están tan acostumbrados a ver NPE lanzado por la máquina virtual, que cualquier programador no se daría cuenta inmediatamente de su error, y comenzaría a mirar al azar, o peor, culpar a su código por ser 'buggy'.

En este caso, IllegalArgumentException transmite información clara al usuario que usa su API de que "no debe ser null". Como señalaron otros usuarios del foro, puede usar NPE si lo desea, siempre y cuando transmita la información correcta al usuario utilizando su API.

GaryF y tweakt eliminaron las referencias "Effective Java" (que juro por) que recomiendan el uso de NPE. Y observar cómo se construyen otras buenas API es la mejor manera de ver cómo construir su API.

Otro buen ejemplo es mirar las API de Spring. Por ejemplo, org.springframework.frijol.BeanUtils.instantiateClass (Constructor ctor, Object[] args) tiene una Afirmación.NotNull (ctor, "Constructor must not be null") línea. org.springframework.útil.Afirmar.El método NotNull(Object object, String message) comprueba si el argumento (object) pasado es null y si lo es lanza una nueva IllegalArgumentException (message) que luego es capturada en el org.springframework.frijol.BeanUtils.instantiateClass(...) método.

Si elige lanzar un NPE y está utilizando el argumento en su método, podría ser redundante y costoso verificar explícitamente un null. Creo que el VM ya hace eso por ti.