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'

  • Error: El recurso esperado de tipo styleable error
  • Los informes de pelusa de Android Studio "no pueden deducir tipos de argumentos".
  • La regla de la lechada personalizada no aparece en el estudio de eclipse / android
  • 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.

  • Android: ¿Para establecer un elemento como seleccionado cuando se abre ListView?
  • ¿Cuál es el mejor IDE para el desarrollo de java android
  • Las tablas de ancho de 100% no funcionan en Gmail Android
  • ¿Es posible utilizar content: // como fuente para un elemento <audio> en un WebView
  • Estilos de herencia múltiple
  • Establecer el color de fondo del título
  • 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.