Как избежать исключения NullPointerException в Java

Вместо шаблона нулевого объекта, который имеет свое применение, вы можете рассмотреть ситуации, когда нулевой объект является ошибкой.

При возникновении исключения изучите трассировку стека и исправьте ошибку.

• Если вы считаете, что объект не должен быть нулевым (или это ошибка), используйте assert.
• Если ваш метод не принимает нулевые параметры, скажите это в javadoc и используйте assert.

Вы должны проверить объект! = Null, только если вы хотите обработать случай, когда объект может быть нулевым ...

Есть предложение добавить новые аннотации в Java7, чтобы помочь с параметрами null / notnull: http://tech.puredanger.com/java7/#jsr308

Иногда у вас есть методы, которые работают с его параметрами, которые определяют симметричную операцию:

a.f(b); <-> b.f(a);

Если вы знаете, что b никогда не может быть нулевым, вы можете просто поменять его местами. Это наиболее полезно для равных: Вместо foo.equals("bar"); лучше сделать "bar".equals(foo);.

В зависимости от того, какие объекты вы проверяете, вы можете использовать некоторые классы из общего числа apache, например: apache commons lang и коллекции Apache Commons

Пример:

String foo;
...
if ( StringUtils.isBlank( foo ) ) {
   ///do something
}

или (в зависимости от того, что вам нужно проверить):

String foo;
...
if ( StringUtils.isEmpty( foo ) ) {
   ///do something
}

Класс StringUtils - только один из многих; В общем, довольно много хороших классов, которые выполняют нулевые безопасные манипуляции.

Вот пример того, как вы можете использовать нулевую валидацию в JAVA, когда вы включаете библиотеку apache (commons-lang-2.4.jar).

public DOCUMENT read(String xml, ValidationEventHandler validationEventHandler) {
    Validate.notNull(validationEventHandler,"ValidationHandler not Injected");
    return read(new StringReader(xml), true, validationEventHandler);
}

И если вы используете Spring, Spring также имеет ту же функциональность в своем пакете, см. Библиотеку (spring-2.4.6.jar)

Пример использования этого статического classf из spring (org.springframework.util.Assert)

Assert.notNull(validationEventHandler,"ValidationHandler not Injected");

Если нулевые значения недопустимы

Если ваш метод вызывается извне, начните с чего-то вроде этого:

public void method(Object object) {
  if (object == null) {
    throw new IllegalArgumentException("...");
  }

Затем в остальной части этого метода вы узнаете, что object не равен нулю.

Если это внутренний метод (не часть API), просто задокументируйте, что он не может быть нулевым, и все.

Пример:

public String getFirst3Chars(String text) {
  return text.subString(0, 3);
}

Однако, если ваш метод просто передает значение, а следующий метод передает его и т. д., Это может вызвать проблемы. В этом случае вы можете проверить аргумент, как указано выше.

Если разрешено значение null

Это действительно зависит. Если обнаружу, что я часто делаю что-то вроде этого:

if (object == null) {
  // something
} else {
  // something else
}

Итак, я разветвляюсь и делаю две совершенно разные вещи. Нет уродливого фрагмента кода, потому что мне действительно нужно делать две разные вещи в зависимости от данных. Например, следует ли мне работать с вводом или рассчитать хорошее значение по умолчанию?

На самом деле я редко использую идиому «if (object != null && ...».

Может быть, будет проще привести примеры, если вы покажете примеры того, где вы обычно используете идиому.

Ответ на этот вопрос указывает на то, что вас могут заинтересовать стратегии обработки ошибок. Как и где обрабатывать ошибки - это широко распространенный архитектурный вопрос. Есть несколько способов сделать это.

Мое любимое: позвольте Исключениям распространяться - ловите их в «основном цикле» или в какой-либо другой функции с соответствующими обязанностями. Проверка условий ошибок и их надлежащая обработка могут рассматриваться как особая ответственность.

Обязательно посмотрите и на аспектно-ориентированное программирование - у них есть изящные способы вставить if ( o == null ) handleNull() в ваш байт-код.

Где бы вы ни передавали массив или вектор, инициализируйте их пустыми, а не нулевыми. - Таким образом можно избежать частых проверок на null, и все в порядке :)

public class NonNullThing {

   Vector vectorField = new Vector();

   int[] arrayField = new int[0];

   public NonNullThing() {

      // etc

   }

}

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

Другими словами, есть два случая, когда возникает нулевая проверка:

1. Где null - действительный ответ с точки зрения контракта; и

2. Где это неверный ответ.

(2) легко. Либо используйте операторы assert (утверждения), либо разрешите сбой (например, Исключение нулевого указателя). Утверждения - это редко используемая функция Java, которая была добавлена ​​в версии 1.4. Синтаксис:

assert <condition>

или же

assert <condition> : <object>

где <condition> - это логическое выражение, а <object> - это объект, выходные данные метода toString() которого будут включены в ошибку.

Оператор assert выдает Error (AssertionError), если условие не выполняется. По умолчанию Java игнорирует утверждения. Вы можете включить утверждения, передав параметр -ea в JVM. Вы можете включать и отключать утверждения для отдельных классов и пакетов. Это означает, что вы можете проверять код с утверждениями при разработке и тестировании и отключать их в производственной среде, хотя мое тестирование практически не показало влияния утверждений на производительность.

Не использовать утверждения в этом случае - нормально, потому что код просто выйдет из строя, что и произойдет, если вы используете утверждения. Единственная разница в том, что с утверждениями это может произойти раньше, более значимым образом и, возможно, с дополнительной информацией, которая может помочь вам выяснить, почему это произошло, если вы этого не ожидали.

(1) немного сложнее. Если у вас нет контроля над кодом, который вы вызываете, вы застряли. Если null является допустимым ответом, вы должны его проверить.

Однако, если это код, который вы контролируете (а это часто бывает), то это совсем другая история. Избегайте использования нулей в качестве ответа. С методами, возвращающими коллекции, это просто: почти все время возвращать пустые коллекции (или массивы) вместо нулей.

С не коллекциями может быть сложнее. Рассмотрим это как пример: если у вас есть эти интерфейсы:

public interface Action {
  void doSomething();
}

public interface Parser {
  Action findAction(String userInput);
}

где Parser принимает необработанный пользовательский ввод и находит, чем заняться, возможно, если вы для чего-то реализуете интерфейс командной строки. Теперь вы можете сделать контракт, чтобы он возвращал значение null, если нет соответствующих действий. Это приводит к нулевой проверке, о которой вы говорите.

Альтернативное решение - никогда не возвращать null и вместо этого использовать Шаблон "Нулевой объект":

public class MyParser implements Parser {
  private static Action DO_NOTHING = new Action() {
    public void doSomething() { /* do nothing */ }
  };

  public Action findAction(String userInput) {
    // ...
    if ( /* we can't find any actions */ ) {
      return DO_NOTHING;
    }
  }
}

Сравнивать:

Parser parser = ParserFactory.getParser();
if (parser == null) {
  // now what?
  // this would be an example of where null isn't (or shouldn't be) a valid response
}
Action action = parser.findAction(someInput);
if (action == null) {
  // do nothing
} else {
  action.doSomething();
}

к

ParserFactory.getParser().findAction(someInput).doSomething();

это намного лучший дизайн, потому что он приводит к более лаконичному коду.

Тем не менее, возможно, для метода findAction () вполне уместно генерировать исключение со значимым сообщением об ошибке - особенно в этом случае, когда вы полагаетесь на ввод пользователя. Было бы намного лучше, если бы метод findAction выдал исключение, чем вызывающий метод выдал простое исключение NullPointerException без каких-либо объяснений.

try {
    ParserFactory.getParser().findAction(someInput).doSomething();
} catch(ActionNotFoundException anfe) {
    userConsole.err(anfe.getMessage());
}

Или, если вы считаете, что механизм try / catch слишком уродлив, вместо «Ничего не делать» ваше действие по умолчанию должно обеспечивать обратную связь с пользователем.

public Action findAction(final String userInput) {
    /* Code to return requested Action if found */
    return new Action() {
        public void doSomething() {
            userConsole.err("Action not found: " + userInput);
        }
    }
}

Только для этой ситуации -

Не проверять, является ли переменная нулевой перед вызовом метода equals (пример сравнения строк ниже):

if ( foo.equals("bar") ) {
 // ...
}

приведет к NullPointerException, если foo не существует.

Этого можно избежать, если сравнить свои String следующим образом:

if ( "bar".equals(foo) ) {
 // ...
}

Я пробовал NullObjectPattern, но для меня это не всегда лучший способ. Бывают случаи, когда «бездействие» неуместно.

NullPointerException - это Исключение времени выполнения, что означает, что это ошибка разработчиков, и при достаточном опыте он сообщает вам, где именно ошибка.

Теперь к ответу:

Постарайтесь сделать все свои атрибуты и их аксессоры как можно более приватными или вообще не открывайте их клиентам. Конечно, вы можете иметь значения аргументов в конструкторе, но, уменьшая область видимости, вы не позволяете клиентскому классу передавать недопустимое значение. Если вам нужно изменить значения, вы всегда можете создать новый object. Вы проверяете значения в конструкторе только однажды, а в остальных методах вы можете быть почти уверены, что значения не равны нулю.

Конечно, опыт - лучший способ понять и применить это предложение.

Байт!

Фреймворк коллекций Google предлагает хороший и элегантный способ достижения нулевой проверки.

В классе библиотеки есть такой метод:

static <T> T checkNotNull(T e) {
   if (e == null) {
      throw new NullPointerException();
   }
   return e;
}

И использование (с import static):

...
void foo(int a, Person p) {
   if (checkNotNull(p).getAge() > a) {
      ...
   }
   else {
      ...
   }
}
...

Или в вашем примере:

checkNotNull(someobject).doCalc();

Вау, мне почти не нравится добавлять еще один ответ, когда у нас есть 57 различных способов порекомендовать NullObject pattern, но я думаю, что некоторые люди, интересующиеся этим вопросом, могут захотеть узнать, что есть предложение для Java 7 добавить "нулевое безопасное обращение" - a оптимизированный синтаксис для логики «если не равно нулю».

Пример, приведенный Алексом Миллером, выглядит так:

public String getPostcode(Person person) {  
  return person?.getAddress()?.getPostcode();  
}  

?. означает отмену ссылки на левый идентификатор только в том случае, если он не равен нулю, в противном случае оцените остаток выражения как null. Некоторым людям, таким как член Java Posse Дик Уолл и избиратели в Devoxx, действительно нравится это предложение, но есть и возражения на том основании, что оно фактически будет способствовать более широкому использованию null в качестве контрольного значения.

Обновлять:официальное предложение для нулевого безопасного оператора в Java 7 был отправлен в Монета проекта.. Синтаксис немного отличается от приведенного выше примера, но это то же самое понятие.

Обновлять: Предложение нулевого оператора не вошло в Project Coin. Таким образом, вы не увидите этого синтаксиса в Java 7.

В конечном счете, единственный способ полностью решить эту проблему - использовать другой язык программирования:

• В Objective-C вы можете сделать эквивалент вызова метода на nil, и абсолютно ничего не произойдет. Это делает ненужными большинство нулевых проверок, но может значительно усложнить диагностику ошибок.
• В Хороший, языке, производном от Java, есть две версии всех типов: потенциально-нулевая версия и ненулевая версия. Вы можете вызывать методы только для ненулевых типов. Типы с потенциально нулевым значением можно преобразовать в типы, отличные от NULL, путем явной проверки на значение NULL. Это значительно упрощает понимание того, где нужны нулевые проверки, а где нет.

Если неопределенные значения недопустимы:

Вы можете настроить свою IDE так, чтобы она предупреждала вас о потенциальном разыменовании null. Например. в Eclipse см. Настройки> Java> Компилятор> Ошибки / предупреждения / анализ нулевого значения.

Если разрешены неопределенные значения:

Если вы хотите определить новый API, в котором неопределенные значения имеют смысл, используйте Вариант шаблона (может быть знаком по функциональным языкам). Он имеет следующие преимущества:

• В API явно указано, существует ли вход или выход.
• Компилятор заставляет вас обрабатывать случай "undefined".
• Вариант - это монада, поэтому нет необходимости в подробной проверке нуля, просто используйте map / foreach / getOrElse или аналогичный комбинатор, чтобы безопасно использовать значение (пример).

Java 8 имеет встроенный класс Optional (рекомендуется); для более ранних версий существуют альтернативные библиотеки, например OptionalГуава или OptionФункциональная Java. Но, как и многие шаблоны функционального стиля, использование Option в Java (даже 8) приводит к довольно некоторому шаблону, который вы можете уменьшить, используя менее подробный язык JVM, например Scala или Xtend.

Если вам нужно иметь дело с API, который может возвращать нули, вы не можете много сделать на Java. Xtend и Groovy имеют Оператор Элвиса?: и нулевой безопасный оператор разыменования?., но обратите внимание, что это возвращает null в случае нулевой ссылки, поэтому он просто «откладывает» правильную обработку null.

Если вы используете (или планируете использовать) Java IDE, например JetBrains IntelliJ IDEA, Затмение или Netbeans, или инструмент, например findbugs, вы можете использовать аннотации для решения этой проблемы.

По сути, у вас есть @Nullable и @NotNull.

Вы можете использовать в методе и параметрах, например:

@NotNull public static String helloWorld() {
    return "Hello World";
}

или же

@Nullable public static String helloWorld() {
    return "Hello World";
}

Второй пример не компилируется (в IntelliJ IDEA).

Когда вы используете первую функцию helloWorld() в другом фрагменте кода:

public static void main(String[] args)
{
    String result = helloWorld();
    if (result != null) {
        System.out.println(result);
    }
}

Теперь компилятор IntelliJ IDEA сообщит вам, что проверка бесполезна, поскольку функция helloWorld() никогда не вернет null.

Использование параметра

void someMethod(@NotNull someParameter) { }

если вы напишете что-то вроде:

someMethod(null);

Это не скомпилируется.

Последний пример с использованием @Nullable

@Nullable iWantToDestroyEverything() { return null; }

Делая это

iWantToDestroyEverything().something();

И можете быть уверены, что этого не произойдет. :)

Это хороший способ позволить компилятору проверить что-то большее, чем обычно, и заставить ваши контракты быть сильнее. К сожалению, это поддерживается не всеми компиляторами.

В IntelliJ IDEA 10.5 и более поздних версиях они добавили поддержку любых других реализаций @Nullable@NotNull.

См. Сообщение в блоге Более гибкие и настраиваемые аннотации @ Nullable / @ NotNull.

Для служебных классов вы можете проверить, что параметры не равны нулю.

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

В дополнение к использованию assert вы можете использовать следующее:

if (someobject == null) {
    // Handle null here then move on.
}

Это немного лучше, чем:

if (someobject != null) {
    .....
    .....



    .....
}

public static <T> T ifNull(T toCheck, T ifNull) {
    if (toCheck == null) {
           return ifNull;
    }
    return toCheck;
}

Другое предложение - программировать защитно - где ваши классы / функции предоставляют значения по умолчанию, которые известны и безопасны, а где null зарезервирован для истинных ошибок / исключений.

Например, вместо функций, которые возвращают строки, возвращающие ноль при возникновении проблемы (например, преобразование числа в строку), пусть они возвращают пустую строку (""). Вам все равно нужно проверить возвращаемое значение, прежде чем продолжить, но особых случаев для исключений не будет. Дополнительным преимуществом этого стиля программирования является то, что ваша программа сможет различать обычные операции и исключения и соответственно реагировать на них.

Вы можете использовать FindBugs. У них также есть плагин Затмение), который помогает вам находить повторяющиеся нулевые проверки (среди прочего), но имейте в виду, что иногда вам следует выбирать защитное программирование. Также может оказаться полезным Контракты для Java.

Действительно, обычная «проблема» в Java.

Во-первых, мои мысли по этому поводу:

Я считаю, что плохо что-то «есть», когда было передано NULL, когда NULL не является допустимым значением. Если вы не выходите из метода с какой-либо ошибкой, это означает, что в вашем методе ничего не произошло, что не соответствует действительности. Тогда вы, вероятно, вернете null в этом случае, и в методе получения вы снова проверяете null, и он никогда не заканчивается, и вы получаете «if! = Null» и т. д.

Итак, IMHO, null должно быть критической ошибкой, которая предотвращает дальнейшее выполнение (то есть, где null не является допустимым значением).

Я решаю эту проблему следующим образом:

Во-первых, я следую этому соглашению:

1. Все общедоступные методы / API всегда проверяют свои аргументы на null
2. Все частные методы не проверяют значение null, поскольку они являются контролируемыми методами (просто дайте умереть с исключением nullpointer, если оно не было обработано выше)
3. Единственные другие методы, которые не проверяют значение null, - это служебные методы. Они общедоступны, но если вы по какой-то причине их вызываете, вы знаете, какие параметры вы передаете. Это все равно, что пытаться вскипятить воду в чайнике без воды ...

И, наконец, в коде первая строка общедоступного метода выглядит так:

ValidationUtils.getNullValidator().addParam(plans, "plans").addParam(persons, "persons").validate();

Обратите внимание, что addParam () возвращает self, поэтому вы можете добавить дополнительные параметры для проверки.

Метод validate() выбрасывает проверенный ValidationException, если какой-либо из параметров равен нулю (установлен или не отмечен - это скорее проблема дизайна / вкуса, но мой ValidationException проверен).

void validate() throws ValidationException;

Сообщение будет содержать следующий текст, если, например, «планы» не заданы:

«Обнаружено недопустимое значение аргумента null для параметра [планы]»

Как видите, второе значение в методе addParam () (строка) необходимо для пользовательского сообщения, потому что вы не можете легко определить переданное имя переменной, даже с отражением (в любом случае, это не тема этого сообщения ...).

И да, мы знаем, что за пределами этой строки мы больше не встретим нулевое значение, поэтому мы просто безопасно вызываем методы для этих объектов.

Таким образом, код будет чистым, легко обслуживаемым и читаемым.

Я фанат кода, работающего без ошибок. Спросите себя, делаете ли вы что-нибудь полезное в случае, если параметр равен нулю? Если у вас нет четкого ответа на вопрос, что ваш код должен делать в таком случае ... оно никогда не должно быть нулевым, а затем игнорировать его и разрешить выброс исключения NullPointerException. Вызывающий код будет иметь такое же значение для NPE, как и для исключения IllegalArgumentException, но разработчику будет легче отладить и понять, что пошло не так, если возникнет NPE, а не ваш код, пытающийся выполнить какое-либо другое непредвиденное обстоятельство. логика - что в конечном итоге приводит к сбою приложения.

Мне нравятся статьи Ната Прайса. Вот ссылки:

• Избегание нулей с помощью полиморфной отправки
• Избегайте нулей с помощью стиля «Говори, не спрашивай»

В статьях также есть ссылка на репозиторий Git для Java Maybe Type, который мне интересен, но я не думаю, что это само по себе могло бы уменьшить проверка раздувания кода. Проведя некоторое исследование в Интернете, я думаю, что раздувание кода ! = ноль можно уменьшить в основном за счет тщательного проектирования.

Еще одна альтернатива:

Следующая простая функция помогает скрыть нулевую проверку (я не знаю почему, но я не нашел ее как часть той же библиотеки общий):

public static <T> boolean isNull(T argument) {
    return (argument == null);
}

Теперь вы можете написать

if (!isNull(someobject)) {
    someobject.doCalc();
}

что, по ИМО, лучший способ выразить != null.

Guava, очень полезная основная библиотека от Google, имеет приятный и полезный API, позволяющий избежать нулей. Я считаю UsingAndAvoidingNullExplained очень полезным.

Как объяснено в вики:

Optional<T> is a way of replacing a nullable T reference with a non-null value. An Optional may either contain a non-null T reference (in which case we say the reference is "present"), or it may contain nothing (in which case we say the reference is "absent"). It is never said to "contain null."

Использование:

Optional<Integer> possible = Optional.of(5);
possible.isPresent(); // returns true
possible.get(); // returns 5

Вы также можете использовать Checker Framework (с JDK 7 и выше) для статической проверки нулевых значений. Это может решить множество проблем, но требует запуска дополнительного инструмента, который в настоящее время работает только с OpenJDK AFAIK. https://checkerframework.org/

Хорошо, теперь я получил технический ответ миллион раз, но я должен сказать это, потому что это нескончаемая дискуссия с Java-программистами.

Извините, но я не согласен почти со всем вышеперечисленным. Причина, по которой мы должны тестировать на null в Java, состоит в том, что Java-программисты не знают, как обращаться с памятью.

Я говорю это, потому что у меня большой опыт программирования на C++, а мы этим не занимаемся. Другими словами, в этом нет необходимости. И обратите внимание, что в Java, если вы нажмете на висящий указатель, вы получите обычное исключение; в C++ это исключение обычно не перехватывается и завершает программу.

Не хочешь этого делать? Тогда следуйте некоторым простым правилам аля C / C++.

Не создавайте экземпляры вещей так легко, считать, что каждый «новый» может доставить вам массу неприятностей, и СОБЛЮДАЙТЕ эти простые правила.

Класс должен обращаться к памяти только тремя способами ->

1. Он может «ИМЕТЬ» учеников класса, и они будут соблюдать следующие правила:

   1. ВСЕ члены «HAS» создаются в конструкторе «новыми».
   2. Вы закроете / удалите выделение в деструкторе или эквивалентном close () функция в Java для того же класса и НИ в каком другом.

Это означает, что вам нужно иметь в виду (как это делает Java), кто является владельцем или родителем каждого ресурса, и уважать это право собственности. Объект удаляется только тем классом, который его создал. Также ->

2. Некоторые участники будут «ИСПОЛЬЗУЮТСЯ», но не будут собственными или «ИМЕЮТ». Это «СОБСТВЕННЫЕ» в другом классе и передаются конструктору в качестве аргументов. Поскольку они принадлежат другому классу, мы НИКОГДА не удалим или закроем его, только родительский элемент может.

3. Метод в классе также может создавать экземпляры локальных объектов для внутреннего использования, которые НИКОГДА не будут выходить за пределы класса, или они должны были быть обычными "имеющими" объектами.

Наконец, чтобы все это работало, вам необходимо иметь дисциплинированный дизайн с классами в иерархической форме и без циклов.

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

Наконец, также помните, что при запуске вашей системы вы должны строить иерархию сверху вниз и разрушать снизу вверх. У вас никогда нигде не будет нулевого указателя или кто-то нарушает правила.

В Java 7 есть новый служебный класс java.util.Objects, в котором есть метод requireNonNull(). Все это вызывает NullPointerException, если его аргумент равен нулю, но это немного очищает код. Пример:

Objects.requireNonNull(someObject);
someObject.doCalc();

Этот метод наиболее полезен для проверка непосредственно перед назначением в конструкторе, где при каждом его использовании можно сохранить три строки кода:

Parent(Child child) {
   if (child == null) {
      throw new NullPointerException("child");
   }
   this.child = child;
}

становится

Parent(Child child) {
   this.child = Objects.requireNonNull(child, "child");
}

Я предпочитаю это

public void simpleFunc(SomeObject someObject){
    someObject = someObject != null ? someObject : new SomeObject(null);
    someObject.doSomething();
}

Конечно, в моем примере SomeObject корректно обрабатывает нулевой параметр. Например, записывать такое событие и больше ничего не делать.

Просто никогда не используйте null. Не позволяй этого.

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

Как только я применил эту практику, я заметил, что проблемы, казалось, исчезли сами собой. Вы поймаете вещи намного раньше в процессе разработки просто случайно и поймете, что у вас есть слабое место ... и, что более важно ... это помогает инкапсулировать проблемы различных модулей, разные модули могут `` доверять '' друг другу и больше не засорять код с конструкциями if = null else!

Это защитное программирование, которое в конечном итоге приводит к гораздо более чистому коду. Всегда дезинфицируйте данные, например здесь путем соблюдения жестких стандартов, и проблемы исчезнут.

class C {
    private final MyType mustBeSet;
    public C(MyType mything) {
       mustBeSet=Contract.notNull(mything);
    }
   private String name = "<unknown>";
   public void setName(String s) {
      name = Contract.notNull(s);
   }
}


class Contract {
    public static <T> T notNull(T t) { if (t == null) { throw new ContractException("argument must be non-null"); return t; }
}

Контракты похожи на мини-модульные тесты, которые всегда выполняются, даже в производственной среде, и когда что-то выходит из строя, вы знаете, почему, а не случайный NPE, который вам нужно как-то выяснить.

Вы можете использовать перехватчик перед вызовом метода. Это то, на чем фокусируется аспектно-ориентированное программирование.

Предположим, что M1 (объектный тест) - это метод, а M2 - это метод, в котором мы применяем аспект перед вызовом метода, M2(Object test2). Если test2 != null, то вызовите M1, в противном случае сделайте другое. Он работает для всех методов, к которым вы хотите применить аспект. Если вы хотите применить аспект для поля экземпляра и конструктора, вы можете использовать AspectJ. Spring также может быть лучшим выбором для аспекта метода.

Во-первых, мы не можем удалить все нулевые условия. Мы можем уменьшить их, используя аннотации @NotNull и @Nullable (как уже упоминалось). Но это должно быть подкреплено какой-то структурой. Здесь может помочь Овал.

Основная идея заключается в том, что объект / параметры / конструктор всегда должны удовлетворять предварительным условиям. У вас может быть множество предварительных условий, таких как Nullable, NotNull и OVal, которые позаботятся о том, чтобы объект был в согласованном состоянии при вызове.

Я предполагаю, что OVal внутренне использует AspectJ для проверки предварительных условий.

@Guarded
public class BusinessObject
{
  public BusinessObject(@NotNull String name)
  {
    this.name = name;
  }

  ...
}

Например,

// Throws a ConstraintsViolatedException because parameter name is null
BusinessObject bo = new BusinessObject(null);

В Java 8 появился новый класс java.util.Optional, который, возможно, решает некоторые проблемы. По крайней мере, можно сказать, что это улучшает читаемость кода, а в случае общедоступных API делает контракт API более понятным для разработчика клиента.

Они так работают:

Необязательный объект для данного типа (Fruit) создается как возвращаемый тип метода. Он может быть пустым или содержать объект Fruit:

public static Optional<Fruit> find(String name, List<Fruit> fruits) {
   for (Fruit fruit : fruits) {
      if (fruit.getName().equals(name)) {
         return Optional.of(fruit);
      }
   }
   return Optional.empty();
}

Теперь посмотрите на этот код, в котором мы ищем в списке Fruit (fruits) данный экземпляр Fruit:

Optional<Fruit> found = find("lemon", fruits);
if (found.isPresent()) {
   Fruit fruit = found.get();
   String name = fruit.getName();
}

Вы можете использовать оператор map() для выполнения вычислений или извлечения значения из необязательного объекта. orElse() позволяет резервировать пропущенные значения.

String nameOrNull = find("lemon", fruits)
    .map(f -> f.getName())
    .orElse("empty-name");

Конечно, проверка нулевого / пустого значения по-прежнему необходима, но, по крайней мере, разработчик осознает, что значение может быть пустым, и риск забыть о проверке ограничен.

В API, созданном с нуля с использованием Optional, всякий раз, когда возвращаемое значение может быть пустым, и возвращать простой объект только тогда, когда он не может быть null (соглашение), клиентский код может отказаться от нулевых проверок для возвращаемых значений простого объекта ...

Конечно, Optional можно также использовать в качестве аргумента метода, возможно, это лучший способ указать необязательные аргументы, чем в некоторых случаях 5 или 10 методов перегрузки.

Optional предлагает другие удобные методы, такие как orElse, который позволяет использовать значение по умолчанию, и ifPresent, который работает с лямбда-выражения.

Я предлагаю вам прочитать эту статью (мой основной источник для написания этого ответа), в которой хорошо объяснены проблема NullPointerException (и вообще нулевой указатель), а также (частичное) решение, предложенное Optional: Необязательные объекты Java.

1. Никогда не инициализируйте переменные нулевым значением.
2. Если (1) невозможно, инициализируйте все коллекции и массивы пустыми коллекциями / массивами.

Делая это в своем собственном коде, вы можете избежать проверок! = Null.

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

// Bad
ArrayList<String> lemmings;
String[] names;

void checkLemmings() {
    if (lemmings != null) for(lemming: lemmings) {
        // do something
    }
}



// Good
ArrayList<String> lemmings = new ArrayList<String>();
String[] names = {};

void checkLemmings() {
    for(lemming: lemmings) {
        // do something
    }
}

В этом есть крошечные накладные расходы, но они того стоят для более чистого кода и меньшего количества исключений NullPointerExceptions.

Мы использовали библиотеки Apache (Apache Commons) для решения этой проблемы.

ObjectUtils.equals(object, null)

или же

CollectionUtils.isEmpty(myCollection);

или же

StringUtils.isEmpty("string");

Мне нравится предыдущий ответ перед, как практика, предоставлением начальных значений по умолчанию или пустых наборов для коллекций, чтобы свести к минимуму необходимость.

Это могут быть простые способы использования, которые не позволяют вам иметь исключение NullPointerException или использовать пустую коллекцию. Это не отвечает на вопрос, что делать с нулевым объектом, но они обеспечивают некоторые проверки для основных проверок объекта или коллекции.

Надеюсь это поможет.

Способ избежать ненужного null-checks прост:

You need to know which variables can be null, and which cannot, and you need to be confident about which category a given variable fall into.

Но, хотя об этом можно сказать достаточно просто, добиться этого труднее. Ключ находится в части confident, потому что как вы можете быть уверены, что переменная не может быть нулевой?

На этот вопрос нет простых и быстрых ответов, но вот несколько советов:

1. Чистый код. Самая важная вещь для рассуждений о поведении фрагмента кода - это то, что он написан в легком для понимания материале. Назовите свои переменные на основе того, что они представляют, назовите свои методы в соответствии с тем, что они делают, примените Single responsibility principle (S в SOLID: http://en.wikipedia.org/wiki/SOLID_(object-oriated_design), это означает, что каждый фрагмент кода должен иметь единственную ответственность и делать это, и ничего больше). После того, как ваш код станет чистым, его будет намного проще рассуждать, в том числе на нескольких уровнях / уровнях кода. В запутанном коде попытка понять, что делает метод, может заставить вас забыть, почему вы вообще читаете этот метод. (Совет: прочтите «Чистый код» Роберта К. Мартина)

2. Избегайте возврата значений null. Если значение null мешает вашей программе работать правильно, вместо этого бросьте exception (обязательно добавьте соответствующую обработку ошибок). Случаи, когда возврат значения null может быть приемлемым, - это, например, попытка получить объект из базы данных. В этих случаях напишите код, который обрабатывает значения null, и отметьте за ухом, что здесь у нас есть что-то, что может вернуть null. Обработайте возвращенные значения null как можно ближе к вызывающему методу, возвращающему null (не просто слепо передавать его обратно в цепочку вызовов).

3. НИКОГДА не передавайте явные значения null в качестве параметров (по крайней мере, не для разных классов). Если вы когда-либо оказывались в ситуации, когда передача параметра null является единственным вариантом, создание нового метода без этого параметра - лучший вариант.

4. Подтвердите свой вклад! Определите «точки входа» в ваше приложение. Они могут все, от веб-сервисов, REST-сервисов, удаленных классов EJB, контроллеров и т. д. Для каждого метода в этих точках входа спросите себя: «Будет ли этот метод выполняться правильно, если этот параметр равен нулю?» Если ответ отрицательный, добавьте Validate.notNull(someParam, "Can't function when someParam is null!");. Это вызовет ошибку IllegalArgumentException, если требуемый параметр отсутствует. Хорошая вещь в этом типе проверки в точках входа заключается в том, что вы можете легко предположить в коде, выполняемом из точки входа, что эта переменная никогда не будет нулевой! Кроме того, если это не удается, находясь в точке входа, отладка становится намного проще, чем если бы вы только что получили NullPointerException глубоко в своем коде, поскольку такой сбой может означать только одно: клиент не отправим вам всю необходимую информацию. В большинстве случаев вы хотите проверить все входные параметры, если вы окажетесь в положении, когда вам нужно разрешить много значений null, это может быть признаком плохо спроектированного интерфейса, который требует рефакторинга / дополнений для удовлетворения потребностей. клиентов.

5. При работе с Collections возвращайте пустой, а не нуль!

6. При работе с базой данных используйте ограничения not null. Таким образом вы узнаете, что значение, считанное из базы данных, не может быть нулевым, и вам не придется его проверять.

7. Структурируйте свой код и придерживайтесь его. Это позволяет вам делать предположения о поведении кода, например, если все входные данные вашего приложения проверены, вы можете предположить, что эти значения никогда не будут нулевыми.

8. Если вы еще этого не сделали, напишите автоматизированные тесты вашего кода. Написав тесты, вы будете рассуждать о своем коде, а также станете более уверенными в том, что он делает то, что должен. Кроме того, автоматические тесты защищают вас от грубых ошибок во время рефакторинга, сразу сообщая вам, что этот фрагмент кода не выполняет то, что раньше.

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

public String nullSafeToString(final Object o) {
    return o != null ? o.toString() : "null";
}

Могу я ответить на него более широко!

Мы, как правило, сталкиваемся с этой проблемой, когда методы получают параметры не так, как мы ожидали (неправильный вызов метода - это ошибка программиста). Например: вы ожидаете получить объект, вместо этого вы получаете ноль. Вы ожидаете получить строку, содержащую хотя бы один символ, вместо этого вы получите пустую строку ...

Итак, нет никакой разницы между:

if (object == null){
   //you called my method badly!

}

или же

if (str.length() == 0){
   //you called my method badly again!
}

Они оба хотят убедиться, что мы получили допустимые параметры, прежде чем выполнять какие-либо другие функции.

Как упоминалось в некоторых других ответах, чтобы избежать вышеуказанных проблем, вы можете следовать шаблону Дизайн по контракту. См. http://en.wikipedia.org/wiki/Design_by_contract.

Чтобы реализовать этот шаблон в Java, вы можете использовать аннотации ядра Java, такие как javax.annotation.NotNull, или использовать более сложные библиотеки, такие как Валидатор гибернации.

Просто образец:

getCustomerAccounts(@NotEmpty String customerId,@Size(min = 1) String accountType)

Теперь вы можете безопасно разработать основную функцию вашего метода без необходимости проверять входные параметры, они защищают ваши методы от неожиданных параметров.

Вы можете пойти дальше и убедиться, что в вашем приложении могут быть созданы только действительные pojos. (образец с сайта валидатора спящего режима)

public class Car {

   @NotNull
   private String manufacturer;

   @NotNull
   @Size(min = 2, max = 14)
   private String licensePlate;

   @Min(2)
   private int seatCount;

   // ...
}

Я считаю, что в этом случае очень полезны предварительные условия Guava. Мне не нравится оставлять нули для исключения нулевого указателя, поскольку единственный способ понять NPE - найти номер строки. Номера строк в производственной и разрабатываемой версиях могут быть разными.

Используя предварительные условия Guava, я могу проверить нулевые параметры и определить значимое сообщение об исключении в одной строке.

Например,

Preconditions.checkNotNull(paramVal, "Method foo received null paramVal");

Это самая частая ошибка, возникающая у большинства разработчиков.

У нас есть несколько способов справиться с этим.

Подход 1:

org.apache.commons.lang.Validate //using apache framework

notNull (объект объекта, строковое сообщение)

Подход 2:

if (someObject!=null){ // simply checking against null
}

Подход 3:

@isNull @Nullable  // using annotation based validation

Подход 4:

// by writing static method and calling it across whereever we needed to check the validation

static <T> T isNull(someObject e){  
   if (e == null){
      throw new NullPointerException();
   }
   return e;
}

Я крайне игнорирую ответы, предлагающие использовать нулевые объекты в любой ситуации. Этот шаблон может разорвать договор и похоронить проблемы все глубже и глубже, вместо того, чтобы решать их, не говоря уже о том, что неправильное использование приведет к созданию еще одной кучи шаблонного кода, который потребует дальнейшего обслуживания.

В действительности, если что-то, возвращаемое из метода, может иметь значение NULL, и вызывающий код должен принять решение по этому поводу, должен быть более ранний вызов, который обеспечивает состояние.

Также имейте в виду, что этот шаблон нулевого объекта будет потреблять память, если его использовать без осторожности. Для этого - экземпляр NullObject должен совместно использоваться владельцами, а не быть уникальным экземпляром для каждого из них.

Также я бы не рекомендовал использовать этот шаблон, когда тип предназначен для представления примитивного типа - например, математические объекты, которые не являются скалярами: векторы, матрицы, комплексные числа и объекты POD (простые старые данные), которые предназначены для хранения состояния. в виде встроенных типов Java. В последнем случае вы закончите вызовом методов получения с произвольными результатами. Например, что должен вернуть метод NullPerson.getName ()?

Такие случаи стоит рассмотреть, чтобы избежать абсурдных результатов.

Вот мой подход ..

class MyObjectHandler
{
public static final int EXCEPTION = (-3);
public static final int INACCESSIBLE = (-2);

public static int doSomething (MyObject obj, MyObjectParameter [] input)
{
    int returnValue= 0;

    try
    {
        if (obj != null)
        {
            returnValue = obj.doSomething(input);
        }
        else
        {
            returnValue = MyObjectHandler.INACCESSIBLE;
        }
    }
    catch (Exception e)
    {
        e.printStack();
        returnValue = MyObjectHandler.EXCEPTION;
    }
    finally
    {
        return returnValue;
    }
}

..

}

Тогда ваш код будет таким:

import xx.xx.xx.MyObjectHandler;
import xx.xx.xx.MyObjectParameter;

class Test
{

    public static void main ()
    {

        MyObject obj = null;

        MyObjectHandler.doSomething(obj, null);

    }

    ..

}

Это очень распространенная проблема для каждого разработчика Java. Таким образом, в Java 8 есть официальная поддержка для решения этих проблем без загромождения кода.

В Java 8 появился java.util.Optional<T>. Это контейнер, который может содержать или не содержать ненулевое значение. Java 8 предоставила более безопасный способ обработки объекта, значение которого в некоторых случаях может быть нулевым. Он вдохновлен идеями Haskell и Scala.

Вкратце, необязательный класс включает методы для явной обработки случаев, когда значение присутствует или отсутствует. Однако преимущество по сравнению с нулевыми ссылками состоит в том, что класс Optional <T> заставляет задуматься о случае, когда значение отсутствует. Как следствие, вы можете предотвратить непреднамеренные исключения нулевого указателя.

В приведенном выше примере у нас есть фабрика домашнего обслуживания, которая возвращает дескриптор для нескольких устройств, доступных в доме. Но эти услуги могут быть доступны / функциональны, а могут и не быть; это означает, что это может привести к исключению NullPointerException. Вместо добавления нулевого условия if перед использованием какой-либо службы давайте заключим его в Optional <Service>.

ПЕРЕДАЧА К ВАРИАНТУ <T>

Давайте рассмотрим способ получения ссылки на услугу с завода. Вместо того, чтобы возвращать ссылку на службу, оберните ее с помощью Optional. Он позволяет пользователю API знать, что возвращенная услуга может быть доступна, а может и не работать, использовать в целях защиты.

public Optional<Service> getRefrigertorControl() {
      Service s = new  RefrigeratorService();
       //...
      return Optional.ofNullable(s);
   }

Как видите, Optional.ofNullable() предоставляет простой способ обернуть ссылку. Есть еще один способ получить ссылку на Optional: Optional.empty() и Optional.of(). Один для возврата пустого объекта вместо перенастройки null, а другой для обертывания объекта, не допускающего значения NULL, соответственно.

ТАК КАК ТОЧНО ЭТО ПОМОГАЕТ ИЗБЕЖАТЬ НУЛЕВОЙ ПРОВЕРКИ?

После того, как вы обернули ссылочный объект, Optional предоставляет множество полезных методов для вызова методов для обернутой ссылки без NPE.

Optional ref = homeServices.getRefrigertorControl();
ref.ifPresent(HomeServices::switchItOn);

Optional.ifPresent вызывает данного Consumer со ссылкой, если это ненулевое значение. В противном случае ничего не делает.

@FunctionalInterface
public interface Consumer<T>

Представляет операцию, которая принимает один входной аргумент и не возвращает результата. Ожидается, что в отличие от большинства других функциональных интерфейсов, Consumer будет работать с побочными эффектами. Это так чисто и легко для понимания. В приведенном выше примере кода вызывается HomeService.switchOn(Service), если необязательная удерживающая ссылка не равна нулю.

Мы очень часто используем тернарный оператор для проверки нулевого условия и возврата альтернативного значения или значения по умолчанию. Необязательно предоставляет другой способ обработки того же условия без проверки null. Optional.orElse (defaultObj) возвращает defaultObj, если Optional имеет нулевое значение. Давайте использовать это в нашем примере кода:

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

Теперь HomeServices.get () делает то же самое, но лучше. Он проверяет, инициализирована ли служба или нет. Если это так, то верните то же самое или создайте новую Новую службу. Необязательный <T> .orElse (T) помогает вернуть значение по умолчанию.

Наконец, вот наш NPE, а также нулевой код без проверки:

import java.util.Optional;
public class HomeServices {
    private static final int NOW = 0;
    private static Optional<HomeServices> service;

public static Optional<HomeServices> get() {
    service = Optional.of(service.orElse(new HomeServices()));
    return service;
}

public Optional<Service> getRefrigertorControl() {
    Service s = new  RefrigeratorService();
    //...
    return Optional.ofNullable(s);
}

public static void main(String[] args) {
    /* Get Home Services handle */
    Optional<HomeServices> homeServices = HomeServices.get();
    if (homeServices != null) {
        Optional<Service> refrigertorControl = homeServices.get().getRefrigertorControl();
        refrigertorControl.ifPresent(HomeServices::switchItOn);
    }
}

public static void switchItOn(Service s){
         //...
    }
}

Полный пост - NPE, а также код без проверки Null… Правда?.

Вы можете связать свой класс с модульным тестированием, используя фреймворк, например JUnit. Таким образом, ваш код будет чистым (без бесполезных проверок), и вы будете уверены, что ваши экземпляры не будут нулевыми.

Это одна из многих хороших причин для использования модульного тестирования.

С помощью лямбда-выражений Java 8 можно определить служебные методы, которые обрабатывают вложенные проверки на null почти красивым образом.

void example() {
    Entry entry = new Entry();
    // This is the same as H-MANs solution 
    Person person = getNullsafe(entry, e -> e.getPerson());    
    // Get object in several steps
    String givenName = getNullsafe(entry, e -> e.getPerson(), p -> p.getName(), n -> n.getGivenName());
    // Call void methods
    doNullsafe(entry, e -> e.getPerson(), p -> p.getName(), n -> n.nameIt());        
}

/** Return result of call to f1 with o1 if it is non-null, otherwise return null. */
public static <R, T1> R getNullsafe(T1 o1, Function<T1, R> f1) {
    if (o1 != null) return f1.apply(o1);
    return null; 
}

public static <R, T0, T1> R getNullsafe(T0 o0, Function<T0, T1> f1, Function<T1, R> f2) {
    return getNullsafe(getNullsafe(o0, f1), f2);
}

public static <R, T0, T1, T2> R getNullsafe(T0 o0, Function<T0, T1> f1, Function<T1, T2> f2, Function<T2, R> f3) {
    return getNullsafe(getNullsafe(o0, f1, f2), f3);
}


/** Call consumer f1 with o1 if it is non-null, otherwise do nothing. */
public static <T1> void doNullsafe(T1 o1, Consumer<T1> f1) {
    if (o1 != null) f1.accept(o1);
}

public static <T0, T1> void doNullsafe(T0 o0, Function<T0, T1> f1, Consumer<T1> f2) {
    doNullsafe(getNullsafe(o0, f1), f2);
}

public static <T0, T1, T2> void doNullsafe(T0 o0, Function<T0, T1> f1, Function<T1, T2> f2, Consumer<T2> f3) {
    doNullsafe(getNullsafe(o0, f1, f2), f3);
}


class Entry {
    Person getPerson() { return null; }
}

class Person {
    Name getName() { return null; }
}

class Name {
    void nameIt() {}
    String getGivenName() { return null; }
}

^{(This answer was first posted here.)}

В Java 8 теперь есть необязательный класс, который обертывает рассматриваемый объект, и если значение присутствует, isPresent () вернет true, а get () вернет значение.

http://www.oracle.com/technetwork/articles/java/java8-optional-2175753.html

Я следую приведенным ниже инструкциям, чтобы избежать нулевых проверок.

1. По возможности избегайте ленивая инициализация переменных-членов. Инициализируйте переменные в самом объявлении. Это обработает исключения NullPointerExceptions.

2. Определите изменчивость переменных-членов в начале цикла. Эффективно используйте языковые конструкции, такие как ключевое слово final.

3. Если вы знаете, что дополнения для метода не будут изменены, объявите их как final.

4. Максимально ограничьте мутация данных. Некоторые переменные могут быть созданы в конструкторе и никогда не могут быть изменены. Удалите общедоступные методы установки, если они действительно не требуются.

   Например. Предположим, что один класс в вашем приложении (A.java) поддерживает коллекцию наподобие HashMap. Не предоставляйте метод получения public в A.java и разрешайте B.java напрямую добавлять элемент в Map. Вместо этого предоставьте API в A.java, который добавляет элемент в коллекцию.

   // Avoid
   a.getMap().put(key,value)
   
   //recommended
   
   public void addElement(Object key, Object value){
          // Have null checks for both key and value here : single place
          map.put(key,value);
   }
   

5. И, наконец, эффективно используйте блоки try{} catch{} finally{} в нужных местах.

Вероятно, лучшей альтернативой для Java 8 или новее является использование класса Optional.

Optional stringToUse = Optional.of("optional is there");
stringToUse.ifPresent(System.out::println);

Это особенно удобно для длинных цепочек возможных нулевых значений. Пример:

Optional<Integer> i = Optional.ofNullable(wsObject.getFoo())
    .map(f -> f.getBar())
    .map(b -> b.getBaz())
    .map(b -> b.getInt());

Пример того, как генерировать исключение для null:

Optional optionalCarNull = Optional.ofNullable(someNull);
optionalCarNull.orElseThrow(IllegalStateException::new);

В Java 7 появился метод Objects.requireNonNull, который может быть полезен, когда что-то нужно проверить на ненулевое значение. Пример:

String lowerVal = Objects.requireNonNull(someVar, "input cannot be null or empty").toLowerCase();

В Java 8 вы можете использовать тип T для локальной переменной / поля / аргумента-метода / типа-возврата, если он никогда не назначал null (и не проверял наличие null), или введите Optional<T>, если он может быть null. Затем используйте метод map для обработки T -> и метод flatMap для обработки T -> Optional<R>:

class SomeService {
    @Inject
    private CompanyDao companyDao;

    // return Optional<String>
    public Optional<String> selectCeoCityByCompanyId0(int companyId) {
        return companyDao.selectById(companyId)
                .map(Company::getCeo)
                .flatMap(Person::getHomeAddress)
                .flatMap(Address::getCity);
    }

    // return String + default value
    public String selectCeoCityByCompanyId1(int companyId) {
        return companyDao.selectById(companyId)
                .map(Company::getCeo)
                .flatMap(Person::getHomeAddress)
                .flatMap(Address::getCity)
                .orElse("UNKNOWN");
    }

    // return String + exception
    public String selectCeoCityByCompanyId2(int companyId) throws NoSuchElementException {
        return companyDao.selectById(companyId)
                .map(Company::getCeo)
                .flatMap(Person::getHomeAddress)
                .flatMap(Address::getCity)
                .orElseThrow(NoSuchElementException::new);
    }
}

interface CompanyDao {
    // real situation: no company for such id -> use Optional<Company> 
    Optional<Company> selectById(int id);
}

class Company {
    // company always has ceo -> use Person 
    Person ceo;
    public Person getCeo() {return ceo;}
}

class Person {
    // person always has name -> use String
    String firstName;
    // person can be without address -> use Optional<Address>
    Optional<Address> homeAddress = Optional.empty();

    public String getFirstName() {return firstName;}   
    public Optional<Address> getHomeAddress() {return homeAddress;}
}

class Address {
    //  address always contains country -> use String
    String country;
    //  city field is optional -> use Optional<String>
    Optional<String> city = Optional.empty();

    String getCountry() {return country;}    
    Optional<String> getCity() {return city;}
}

Шаблон нулевого объекта можно использовать в качестве решения этой проблемы. Для этого следует изменить класс someObject.

public abstract class SomeObject {
   public abstract boolean isNil();
}

public class NullObject extends SomeObject {
   @Override
   public boolean isNil() {
      return true;
   }
}
public class RealObject extends SomeObject {
   @Override
   public boolean isNil() {
      return false;
   }
}

Теперь вместо проверки,

 if (someobject != null) {
    someobject.doCalc();
}

Мы можем использовать,

if (!someObject.isNil()) {
   someobject.doCalc();
}

Ссылка: https://www.tutorialspoint.com/design_pattern/null_object_pattern.htm

Начиная с Java 7 существует класс java.util.Objects.

Но начиная с Java 8, вы можете использовать методы Objects.isNull(var) и Objects.nonNull(var) класса Objects для проверки нулевого указателя.

Например,

String var1 = null;
Date var2 = null;
Long var3 = null;

if (Objects.isNull(var1) && Objects.isNull(var2) && Objects.isNull(var3))
    System.out.println("All Null");
else if (Objects.nonNull(var1) && Objects.nonNull(var2) && Objects.nonNull(var3))
    System.out.println("All Not Null");

Если вы используете java8 или более позднюю версию, выберите isNull(yourObject) от java.util.Objects.

Пример:-

String myObject = null;

Objects.isNull(myObject); //will return true

Использование: приведенный ниже код возвращает ненулевое значение (если имя не равно нулю, то это значение будет возвращено, иначе будет возвращено значение по умолчанию).

final String name = "Jobin";
String nonNullValue = Optional.ofNullable(name).filter(Objects::nonNull).orElse("DefaultName");

Java 8 представила новый класс Optional в пакете java.util.

Преимущества Java 8 Дополнительно:

1.) Нулевые проверки не требуются. 2.) Больше никаких исключений NullPointerException во время выполнения. 3.) Мы можем разрабатывать чистые и аккуратные API.

По желанию - объект-контейнер, который может содержать или не содержать ненулевое значение. Если значение присутствует, isPresent () вернет true, а get () вернет значение.

Для получения дополнительной информации найдите здесь документы оракула: - https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html

В общем, чтобы избежать заявления

if (object != null) {
    ....
}

1. начиная с java 7 вы можете использовать методы Objects:

   Objects.isNull (объект)

   Objects.nonNull (объект)

   Objects.requireNonNull (объект)

   Objects.equals (объект1, объект2)

2. начиная с java 8 вы можете использовать необязательный класс (когда использовать)

object.ifPresent(obj -> ...); Java 8

object.ifPresentOrElse(obj -> ..., () -> ...); Java 9

3. полагаться на контракт метода (JSR 305) и использовать Найдите ошибки. Пометьте свой код аннотациями @javax.annotation.Nullable и @javax.annotation.Nonnnul. Также имеются предварительные условия.

   Preconditions.checkNotNull (объект);

4. В особых случаях (например, для строк и коллекций) вы можете использовать служебные методы apache-commons (или Google guava):

public static boolean isEmpty(CharSequence cs) //apache CollectionUtils

public static boolean isEmpty(Collection coll) //apache StringUtils

public static boolean isEmpty(Map map) //apache MapUtils

public static boolean isNullOrEmpty(@Nullable String string) //Guava Strings

5. Когда вам нужно назначить значение по умолчанию, когда null, используйте apache commons lang

public static Object defaultIfNull(Object object, Object defaultValue)

Один вариант, который у вас есть

• Используйте фреймворк для проверки @RequiresNonNull в методах. например, вы получите это, если вызовете метод, аннотированный как таковой, с нулевым аргументом. Он не сработает во время компиляции, даже до запуска вашего кода! поскольку во время выполнения это будет NullPointerException

  @RequiresNonNull(value = { "#1" })
  static void check( Boolean x) {
      if (x) System.out.println("true");
      else System.out.println("false");
  }
  
  public static void main(String[] args) {
  
  
      check(null);
  
  }
  

получает

[ERROR] found   : null
[ERROR] required: @Initialized @NonNull Boolean
[ERROR] -> [Help 1]

Существуют и другие методы, такие как Use Java 8 Optional, Guava Annotations, Null Object pattern и т. д. Не имеет значения, если вы достигли своей цели избежать! = Null

В Java 8 вы можете передать поставщика вспомогательному методу, как показано ниже,

if (CommonUtil.resolve(()-> a.b().c()).isPresent()) {

}

Выше заменяет код котельной плиты, как показано ниже,

if (a!=null && a.b()!=null && a.b().c()!=null) {

}

//CommonUtil.java

 public static <T> Optional<T> resolve(Supplier<T> resolver) {
        try {
            T result = resolver.get();
            return Optional.ofNullable(result);
        } catch (NullPointerException var2) {
            return Optional.empty();
        }
    }

Вы можете избежать многого, чтобы избежать NullPointerException, просто следуя большинству других ответов на вопрос, я просто хочу добавить несколько больше способов, которые были введены в Java 9, чтобы изящно справиться с этим сценарием, а также продемонстрировать, что некоторые из старых также можно использовать и, таким образом, уменьшить усилия.

1. public static boolean isNull(Object obj)

   Возвращает истину, если предоставленная ссылка равна нулю, в противном случае возвращает ложный.

   Начиная с Java 1.8

2. public static boolean nonNull(Object obj)

   Возвращает истину, если предоставленная ссылка не равна нулю, в противном случае возвращает ложный.

   Начиная с Java 1.8

3. public static <T> T requireNonNullElse​(T obj, T defaultObj)

   Возвращает первый аргумент, если он не равен нулю, и в противном случае возвращает ненулевой второй аргумент.

   Начиная с Java 9

4. public static <T> T requireNonNullElseGet​(T obj, Supplier<? extends T> supplier)

   Возвращает первый аргумент, если он не равен нулю, и в противном случае возвращает ненулевое значение supplier.get ().

   Начиная с Java 9

5. public static <T> T requireNonNull​(T obj, Supplier<String> messageSupplier)

   Проверяет, что указанная ссылка на объект не является нулевой, и в противном случае выдает настраиваемое исключение NullPointerException.

   Начиная с Java 1.8

Более подробную информацию о вышеуказанных функциях можно найти в здесь.

Котлин с нулевой безопасностью - элегантная альтернатива, но это означает большее изменение.

Функциональный подход может помочь обернуть повторяющиеся нулевые проверки и выполнить анонимный код, как в примере ниже.

    BiConsumer<Object, Consumer<Object>> consumeIfPresent  = (s,f) ->{
        if (s!=null) {
            f.accept(s);
        }
    };

    consumeIfPresent.accept(null, (s)-> System.out.println(s) );
    consumeIfPresent.accept("test", (s)-> System.out.println(s));

    BiFunction<Object, Function<Object,Object>,Object> executeIfPresent  = (a,b) ->{
        if (a!=null) {
            return b.apply(a);
        }
        return null;
    };
    executeIfPresent.apply(null, (s)-> {System.out.println(s);return s;} );
    executeIfPresent.apply("test", (s)-> {System.out.println(s);return s;} );

Другой альтернативой проверке! = Null является (если вы не можете избавиться от нее с точки зрения дизайна):

Optional.ofNullable(someobject).ifPresent(someobject -> someobject.doCalc());

или же

Optional.ofNullable(someobject).ifPresent(SomeClass::doCalc);

SomeClass - это тип какого-то объекта.

Однако вы не можете получить возвращаемое значение из doCalc (), поэтому полезно только для методов void.

Java 8 представила новый класс Optional в пакете java.util. Он используется для обозначения наличия или отсутствия значения. Основное преимущество этой новой конструкции заключается в том, что больше не требуется слишком много нулевых проверок и NullPointerException. Он избегает любой среды выполнения NullPointerExceptions и поддерживает нас в разработке чистых и аккуратных Java API или приложений. Подобно Collections и arrays, он также является Контейнером для хранения не более одного значения.

Ниже приведены полезные ссылки, по которым вы можете перейти

https://www.mkyong.com/java8/java-8-optional-in-depth/

https://dzone.com/articles/java-8-optional-avoid-null-and

Вы можете создать один общий метод для объекта и строки, чтобы вы могли использовать его в своем приложении - Это может помочь вам и вашим коллегам: Создайте класс, например. StringUtilities и добавьте метод, например. getNullString

public static String getNullString(Object someobject)
{
   if (null==someobject )
        return null;

   else if (someobject.getClass().isInstance("") && 
          (((String)someobject).trim().equalsIgnoreCase("null")|| 
          ((String)someobject).trim().equalsIgnoreCase("")))
        return null;

   else if (someobject.getClass().isInstance(""))
        return (String)someobject;

   else
        return someobject.toString().trim();
}

И просто назовите этот метод как,

if (StringUtilities.getNullString(someobject) != null)
{ 
  //Do something
}

Лучший способ избежать нулевых проверок в Java - это правильно обрабатывать и использовать исключения. По моему опыту, проверки на NULL стали более распространенными и требующимися по мере того, как вы приближаетесь к интерфейсу, потому что он ближе к пользователю, который может предоставить неверную информацию через пользовательский интерфейс (например, отсутствие значения, отправляемое для поля).

Кто-то может возразить, что вы должны иметь возможность контролировать то, что делает пользовательский интерфейс, чтобы вы не забыли, что большая часть пользовательского интерфейса выполняется через какую-то стороннюю библиотеку, которая, например, может возвращать либо NULL, либо пустую строку для пустого текстового поля, в зависимости от ситуации или библиотеки.

Вы можете комбинировать их так:

try
{
  myvar = get_user_supplied_value(); 
  if (!myvar || myvar.length() == 0) { alert_the_user_somehow(); return; };

  process_user_input(myvar);
} catch (Exception ex) {
  handle_exception(ex);
}

Другой подход, который используют люди, - это сказать:

if (myvar && myvar.length() > 0)  { };

Вы также можете создать исключение (что я предпочитаю)

if (!myvar || myvar.length() == 0) {
 throw new Exception("You must supply a name!");
};

Но решать только вам.

Есть хороший способ проверить нулевое значение из JDK. Это Optional.java, в котором есть море методов для решения этих проблем. Такие как следующие: `

• Returns an {@code Optional} describing the specified value, if non-null,
  • в противном случае возвращает пустой {@code Optional}.
  • @param класс значения
  • @param value возможное значение NULL для описания
  • @ return an {@code Optional} с текущим значением, если указанное значение
  • не равно NULL, в противном случае - пустой {@code Optional}

public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
}  `

`/

• Вернуть {@code true}, если есть значение, иначе {@code false}. *

  • @return {@code true}, если есть значение, иначе {@code false} * / public boolean isPresent () { возвращаемое значение! = null; }

  / **

  • Если значение присутствует, вызвать указанного потребителя со значением,
  • в противном случае ничего не делать.
  • Потребительский блок @param, который будет выполняться, если присутствует значение
  • @throws NullPointerException, если значение присутствует и {@code consumer} равно
  • нулевой * / public void ifPresent (Consumer <? super T> consumer) { если (значение! = ноль) consumer.accept (значение); } `

Очень-очень полезно помогать джаверу.

public class Null {

public static void main(String[] args) {
    String str1 = null;
    String str2 = "";

    if (isNullOrEmpty(str1))
        System.out.println("First string is null or empty.");
    else
        System.out.println("First string is not null or empty.");

    if (isNullOrEmpty(str2))
        System.out.println("Second string is null or empty.");
    else
        System.out.println("Second string is not null or empty.");
}

public static boolean isNullOrEmpty(String str) {
    if (str != null && !str.isEmpty())
        return false;
    return true;
}
}

Выход

str1 is null or empty.
str2 is null or empty.

В приведенной выше программе у нас две строки str1 и str2. str1 содержит нулевое значение, а str2 - пустая строка.

Мы также создали функцию isNullOrEmpty (), которая проверяет, как следует из названия, является ли строка нулевой или пустой. Он проверяет его, используя нулевую проверку, используя метод строки! = Null и isEmpty ().

Проще говоря, если строка не является нулем, а isEmpty () возвращает false, она не является ни нулевым, ни пустым. В противном случае это так.

Однако указанная выше программа не возвращает пустое значение, если строка содержит только символы пробела (пробелы). Технически isEmpty () видит, что он содержит пробелы, и возвращает false. Для строки с пробелами мы используем строковый метод trim (), чтобы вырезать все начальные и конечные символы пробелов.