Ответ 1
Если рассматриваемая проверка была lint, был бы способ настройки lintOptions
внутри вашего build.gradle
, чтобы заставить сборки не сработать, как в ответах на этот вопрос здесь
Однако проверка, о которой вы говорите, предоставляется самой IDE в Android Studio. В настоящее время нет способа остановить сборку для этих проверок, согласно этому каноническому ответу от разработчика IntelliJ Вот ссылку на документацию для этого статического анализа кода, предоставляемого IntelliJ. В рамках анализа, описанного в документации, конкретное имя - "Константные условия и исключения":
Эта проверка анализирует контроль методов и поток данных для сообщения о возможных условиях, которые всегда являются истинными или ложными, выражения, значение которых статически доказано как постоянное, и ситуации, которые могут привести к нарушениям контракта с ошибкой. Переменные, параметры метода и возвращаемые значения, помеченные как @Nullable или @NotNull, обрабатываются как NULL (или не-null, соответственно) и используются во время анализа для проверки контрактов с недействительностью, например. сообщить о возможных ошибках NullPointerException.
Я думаю, что лучшее, что вы можете сделать, это изменить его серьезность, чтобы оно выглядело как предупреждение (красное подчеркнуто в IDE). Сделайте это так, перейдите в раздел "Предпочтения/проверки/вероятные ошибки" и измените строгость "константных условий и исключений" на предупреждение:
Ваш проект по-прежнему будет построен, если вы проигнорируете предупреждение, но оно не выглядит красивым:
Вам нужно будет настроить его так, чтобы ваша команда делилась теми же настройками проверки кода Android Studio. Вы можете сделать это с помощью репозитория настроек.
Обратите внимание, что вы также можете включить параметр "Зафиксировать изменения/выполнить проверку кода", который заставит анализ кода до того, как команда совершит.
Когда вы нажимаете commit, он сначала выполняет анализ и находит предупреждение, о котором вы говорили:
Также обратите внимание, что принуждение команды к проведению таких проверок может быть не лучшим вариантом, если NPE становятся проблематичными в проекте. Вместо этого вы можете попробовать такие параметры, как обсуждение открытых проблем, возвращающих null
и возможных решений. Отличная статья об исключении null в вики Google Guava - отличная отправная точка.