Join FlipAndroid.COM Telegram Group: https://t.me/joinchat/F_aqThGkhwcLzmI49vKAiw


Manera correcta de manejar la advertencia de pelusa de NullPointerException de Android Studio

Soy nuevo en la programación de android / java y estoy confundido cómo tratar correctamente con esta advertencia.

Invocación de método '' puede producir 'Java.lang.NullPointerException'

Introduzca aquí la descripción de la imagen

¿Debería ser yo mismo afirmar que eliminaría la advertencia? Introduzca aquí la descripción de la imagen

¿O más bien una excepción de tiempo de ejecución? Introduzca aquí la descripción de la imagen

Cualquier ayuda sería apreciada.

  • ¿Qué significa este Android Lint: "Orientación errónea?"
  • Selector, lista de capas y forma / mapa de bits en el mismo xml
  • Cómo suprimir Android Lint advertencia en Gradle script
  • Los recursos no utilizados de la capa de androide del módulo de la biblioteca se utilizan en la aplicación
  • ¿Cómo añadir -Xlint: desmarcado a mi proyecto basado en Android Gradle?
  • Limpieza de los permisos de Android no utilizados
  • Custom Lint para Java / Android Informe si encontramos una llamada de clase sin implementar su interfaz
  • La regla de la lechada personalizada no aparece en el estudio de eclipse / android
  • 6 Solutions collect form web for “Manera correcta de manejar la advertencia de pelusa de NullPointerException de Android Studio”

    Dudo que esta pregunta pueda ser contestada de manera concluyente, ya que es una cuestión de opinión. O al menos lo creo, una opinión también. 🙂

    Entiendo que quieres "0 advertencias" (un objetivo muy loable) pero probablemente no haya un problema de "talla única". Dicho esto …

    Cosas que creo que no debes hacer:

    • Utilice afirmación . Si bien puede agregar una declaración afirmativa, Dalvik las ignora. Puede configurar un emulador para usarlos si lo desea, pero no un dispositivo real (consulte ¿Puedo usar assert en dispositivos Android? ). Así que mientras que posiblemente quitar la advertencia, es inútil en la práctica.
    • Haga que el método lance NullPointerException . Esto sería una mala idea, en general. En este caso, ya que probablemente está sobreescribiendo onOptionsItemSelected() , ni siquiera es posible.

    Comprobar (variable != null) es generalmente el mejor enfoque. Qué hacer si es, sin embargo, presenta algunas otras opciones.

    • Si se trata de un problema del que puede recuperarse , es decir, puede continuar con la aplicación aunque el searchView no esté allí, solo hágalo. Por ejemplo, simplemente regrese del método. Es una buena idea registrar esta situación sin embargo, así que usted puede mancharla mientras que prueba.
    • De lo contrario, si no es posible continuar, lance una excepción. Usted quiere fallar temprano , para que el problema pueda ser fácilmente detectado. Una excepción razonable para este caso sería IllegalStateException (consulte Java equivalente a .NET System.InvalidOperationException ). Básicamente indica que este método se ejecutó en un momento inapropiado. Tenga cuidado, sin embargo, que como una excepción RuntimeException , estas excepciones están desmarcadas y, por lo tanto, probablemente hará que la aplicación se bloquee.

    Empecé a usar

    @SuppressWarnings("ConstantConditions")

    En métodos simples donde estoy seguro de que el id no es nulo.

    Como @matiash señaló que no hay una solución de talla única.

    Para mí un buen compromiso fue desactivar la advertencia NullPointerException para todas las llamadas a findViewById() y mantenerlo para otras llamadas de método. De esa manera me responsabilizo de revisar los identificadores de recursos, pero aún así obtener un beneficio de recibir advertencias si cometo otros errores.

    Para lograr esto, agregué el contrato de método _ -> !null con el menú de arreglos rápidos de Android Studio.

    La acción generó un archivo de archivo siguiente en android/support/v7/app/annotations.xml en mi raíz del proyecto.

     <root> <item name='android.support.v7.app.AppCompatActivity android.view.View findViewById(int)'> <annotation name='org.jetbrains.annotations.Contract'> <val val="&quot;_ -&gt; !null&quot;" /> </annotation> </item> </root> 

    Actualización: Desafortunadamente no sobrevive Android Studio se reinicia 🙁 Las anotaciones externas son realmente útiles por lo que espero encontrar una forma de hacer Android Studio cargarlos después de reiniciar.

    Me gusta la respuesta a este enlace .

    Advertencia no es un error. Y la advertencia que usted está hablando dice que "puede producir", no dice "debe producir". Así que la elección es suya. Añada cheque nulo o no

    Por lo tanto, si está seguro de que findViewById en su código nunca será causa de NPE, entonces no agregue la comprobación nula.

    Yo personalmente prefiero usar try {} catch {} simplemente porque es más elegante. Sin embargo, se agrega un montón de volumen a su código, si usted se imagina poner todos los valores posibles, NULL en un try catch (si no están al lado del otro)

    Sí. Usar if (Object != null){} para validar es la forma correcta. try {} catch (NullPointerException) {} es la siguiente solución que se prefiere en este caso.

    Si usted quiere conseguir el paseo de él, lanzar un NullPointerException . Lint lo ignorará en este caso. public void myFunc() throws NullPointerException{} .

    De todos modos, una buena codificación siempre significa validar todo para un posible problema mientras se ejecuta. Validating != null está bien y siempre se debe usar siempre que sea posible null.

    FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.