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

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

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

Вещи, которые, как я считаю, вам не следует делать:

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

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

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

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

@SuppressWarnings("ConstantConditions")

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

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

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

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

Действие создало следующий файл в файле 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-студия перезапускает 🙁 Внешние аннотации действительно полезны, поэтому я надеюсь, что я смогу заставить Android Studio загрузить их после перезагрузки.

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

Предупреждение не является ошибкой. И предупреждение, о котором вы говорите, говорит «оно может произвести», не говорите «оно должно произвести». Поэтому выбор за вами. Либо добавьте нулевую проверку, либо нет.

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

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

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

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

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