Правильный способ обработки предупреждения NullPointerException от Android Studio

Я новичок в программировании на android / java и запутался, как правильно справиться с этим предупреждением.

вызов метода "может привести к" Java.ленг.NullPointerException'

enter image description here

должен ли я ussing assert удалить предупреждение? enter image description here

или, скорее, исключение во время выполнения? enter image description here

любая помощь будет оценили.

31
android android-studio java lint nullpointerexception

7 ответов

Я сомневаюсь, что на этот вопрос можно ответить окончательно, так как это вопрос мнения. Или, по крайней мере, я так думаю-тоже мнение. :)

Я понимаю, что вы хотите "0 предупреждений" (очень похвальная цель), но, вероятно, нет проблемы "один размер подходит всем". Вот и все...

вещи, я считаю, что вы должны не do:

  • использовать assert. Хотя вы можете добавить оператор assert, Dalvik игнорирует их. Можно настроить эмулятор использовать их, если хотите, но не реальное устройство (см. могу ли я использовать assert на устройствах Android?). Поэтому, хотя это, возможно, удалит предупреждение, это бесполезно на практике.
  • есть метод throw NullPointerException. Вообще-то это плохая идея. В этом случае, так как вы, вероятно,переопределение onOptionsItemSelected(), это даже невозможно.

проверка (variable != null) как правило, лучший подход. Что делать, если это, хотя, представляет некоторые другие опции.

  • если это проблема, вы можете восстановить from, т. е. вы можете продолжить приложение, даже если searchView нет, просто сделайте это. Например, просто вернитесь из метода. Это хорошая идея log этой ситуации, хотя, так что вы можете обнаружить его во время тестирования.
  • в противном случае, если продолжение не возможно, исключение. Вы хотите не рано, так, что проблему можно легко обнаружить. Ля разумным исключением для этого случая будет IllegalStateException (см. Java эквивалентно системе .NET.Исключение InvalidOperationException). Это в основном указывает на то, что этот метод был выполнен в неподходящее время. Будьте осторожны, хотя, что как RuntimeException, эти исключения не отмечены, и, следовательно, вероятно, приведет к сбою приложения.
25

Я начал использовать

@SuppressWarnings("ConstantConditions")

на простых методах, где я уверен, что идентификатор не равен null.

22

Я лично предпочитаю использовать try{ }catch{ } просто потому, что он более элегантный. Тем не менее, он добавляет много массы в ваш код, если вы представляете себе, помещая каждое возможное значение NULL в try catch (если они не находятся рядом друг с другом)

1

как отметил @matiash, нет единого решения для всех размеров.

для меня хорошим компромиссом было отключить NullPointerException предупреждение для всех вызовов findViewById() и сохранить его для других вызовов методов. Таким образом, я беру на себя ответственность за проверку идентификаторов ресурсов, но все равно получаю предупреждение, если делаю другие ошибки.

для достижения этого я добавил _ -> !null метод контракт с Android Studio quick fix меню.

действие создало следующий файл файл android/support/v7/app/annotations.xml в корне проекта.

<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>

обновление: К сожалению, он не переживает перезагрузки Android Studio :-( Внешние аннотации действительно полезны, поэтому я надеюсь, что найду способ заставить Android Studio загрузить их после перезагрузки.

1

да. Используя if (Object != null){} для проверки правильно. try {} catch (NullPointerException) {} является следующим решением, которое является предпочтительным в этом случае.

если вы хотите прокатиться на нем, бросьте NullPointerException. В этом случае Линт проигнорирует его. public void myFunc() throws NullPointerException{}.

в любом случае, хорошее кодирование всегда означает проверку всего на возможную проблему во время выполнения. Проверка != null просто отлично и всегда должно использоваться, когда это возможно null.

1

что @Herrbert74 предположил, что он наверняка работает нормально, но иногда лучше не добавлять @SuppressWarnings("ConstantConditions") для всего метода (если это не тривиально), лучшим подходом может быть использование //noinspection ConstantConditions на предупрежденной линии.

мои правила:

  • использовать @SuppressWarnings("ConstantConditions") когда метод прост

  • использовать //noinspection ConstantConditions когда этот метод сложный и вам нужно удалить только на определенной строке

1

Мне нравится ответ на этот ссылке.

предупреждение не является ошибкой. И предостережение, о котором вы говорите говорит:" оно может производить", не говорите: "оно должно производить". Так что выбор есть твой. Либо добавить нулевую проверку, либо нет

Итак, если вы уверены, что findViewById в вашем коде никогда не будет причиной из NPE, то не добавляйте проверку null.

0