Requirenonnull java что это
Учимся избегать null-значений в современном Java. Часть 2
Возвращайте Optional вместо null
Хоть в предыдущей статье я и убеждал вас в уместности null для некоторых сценариев, в этой я буду напротив говорить, что по возможности его все же лучше избегать. При каждом добавлении в базу кода нового метода, способного вернуть пустое значение, вам следует стараться использовать вместо null тип Optional. Этот тип был введен, чтобы разработчики могли указывать на возможность возвращения методом пустого значения, что ранее было недоступно (либо требовало аннотаций, о которых я расскажу ниже). Существует два вида объектов Optional : содержащие значение и без него. Первые изначально создаются со значением, вторые же просто являются статическими одиночками. Структурно типичный случай их использования выглядит так:
Чтобы увидеть, почему сигнатура с Optional предпочтительней, представьте следующий метод:
Поскольку смысл использовать Optional есть только в случае возможного возврата пустого значения, значит метод такое значение вернуть может. Поэтому при каждом возвращении Optional методом вы знаете, что есть вероятность получения пустого значения и его нужно должным образом обработать.
Со значением Optional соответствующий код будет выглядеть так:
Однако если бы вместо этого у нас был метод, возвращающий активную госпитализацию, то предпочтительнее было бы использовать Optional :
Можно ли использовать Optional для параметров?
Никогда не делайте следующее, равно как не предоставляйте null в качестве аргумента параметра с Optional значением:
Если вы сделаете нечто подобное, то также получите NPE (исключение нулевого указателя).
Содействуйте IDE с помощью аннотаций Nullable/Nonnull
Вот один из примеров подобной сигнатуры метода:
Используйте Objects.requireNonNull()
Здесь у вас может возникнуть вопрос, заключается ли причина избегания нулевого параметра в том, что он может ненамеренно привести к NPE. Не будет ли лучше выбросить NPE намеренно до того, как это произойдет?
Скорее всего, это одно и то же, и с позиции пользователя выглядеть это будет тоже одинаково — в виде появления ошибки. А вот при диагностировании причины сбоя в дальнейшем, последний вариант окажется гораздо предпочтительнее. Проблема с NPE в том, что они не сообщают, какая переменная оказалась null, а просто предоставляют номер строки. В строке, где для объектов вызывается несколько методов, может быть сложно определить, в каком из них причина.
Предположим, вы получаете NPE в следующей строке кода:
Выбрасывание собственного исключения для пустого значения параметра будет тут же показывать в лог-файлах, где искать проблему, потому что на нее будет указывать ваше собственное сообщение об ошибке.
Работа со строками
Используйте класс Objects и библиотеку StringUtils
Ошибки нередко прокрадываются в базу кода, когда у нас нет ясного понимания того, что код делает или почему он это делает. Здесь важно удобство в обслуживании. Я часто сталкиваюсь с запутанным кодом создания строки. По какой-то причине люди склонны увлекаться тернарными выражениями, помещая их в другие выражения или вкладывая друг в друга. Это очень эффективно усложняет чтение и понимание простой логики.
Не так складно, как в примере с C#, но, на мой взгляд, намного надежнее, чем исходный пример, а значит и шанс появления ошибок при работе с кодом уже существенно меньше.
Используйте StringUtils для защиты String-методов от null
Заключение
Вкратце содержание рассмотренной серии статей можно выразить так:
Java.util.Objects класс в Java
В Java 7 появился новый класс Object, который имеет 9 статических служебных методов для работы с объектами. Эти утилиты включают в себя нулевые безопасные методы для вычисления хеш-кода объекта, возврата строки для объекта и сравнения двух объектов.
Используя методы класса Objects, можно хитро обрабатывать исключение NullPointerException, а также отображать настроенное сообщение NullPointerException (если возникает исключение).
// Java-программа для демонстрации Objects.toString (Object o)
// и Objects.toString (Object o, String nullDefault) методы
public Pair(K key, V value)
public String toString() <
Objects.toString(value, «no value» ) + «>» ;
/ * без Objects.toString (Object o) и
Метод Objects.toString (Object o, String nullDefault)
«, value =» + (value == null? «no value»: value.toString ()) + «>»; * /
public static void main(String[] args)
// Java-программа для демонстрации метода equals (Object a, Object b)
public Pair(K key, V value)
public boolean equals(Object o)
if (!(o instanceof Pair)) <
public static void main(String[] args)
// Java-программа для демонстрации Objects.requireNonNull (Object o)
// и Objects.requireNonNull (Object o, String message) методы
public Pair(K key, V value)
public void setKey(K key) <
public void setValue(V value) <
public static void main(String[] args)
// оператор ниже выкинет NPE с настроенным сообщением
// Java-программа для демонстрации объекта Objects.hashCode (Object o)
public Pair(K key, V value)
public int hashCode()
return (Objects.hashCode(key) ^ Objects.hashCode(value));
/ * без метода Objects.hashCode (Object o)
return (key == null? 0: key.hashCode ()) ^
(значение == ноль? 0: значение.hashCode ()); * /
public static void main(String[] args)
Почему следует использовать Objects.requireNonNull ()?
Один очевидный ответ (или преимущество) состоит в том, что он делает код более читабельным, и я согласен. Я хотел бы знать любые другие причины для использования Objects.requireNonNull() в начале метода.
Теперь ты знаешь :
Сравните это с: вы создаете объект Foo сегодня, а завтра вы вызываете метод, который использует это поле и создает его. Скорее всего, завтра вы не узнаете, почему эта ссылка была нулевой вчера, когда она была передана конструктору!
Основными преимуществами являются:
Fail-быстрый
Код должен вылететь как можно скорее. Он не должен выполнять половину работы, а затем разыменовывать нулевое значение и падать только тогда, когда оставляется половина выполненной работы, в результате чего система находится в недопустимом состоянии.
Но NullPointerException будет выброшено в любом случае, если нулевой объект разыменован. Итак, зачем делать эту дополнительную проверку на нуль и генерировать исключение NullPointerException?
Использование в requireNonNull() качестве первых утверждений в методе позволяет прямо / быстро определить причину исключения.
Трассировка стека четко указывает на то, что исключение было сгенерировано сразу после ввода метода, поскольку вызывающая сторона не соблюдала требования / контракт. Передача null объекта другому методу может действительно вызывать исключение за один раз, но причина проблемы может быть более сложной для понимания, поскольку исключение будет вызвано определенным вызовом null объекта, который может быть намного дальше.
Теперь предположим «плохую» реализацию Dictionary без null проверки в записи метода (здесь это конструктор):
Теперь давайте вызовем Dictionary конструктор со null ссылкой на words параметр:
JVM бросает NPE в этом заявлении:
Таким образом, способ одолеть это
Таким образом, нет головной боли: мы получаем исключение, как только это получено:
Обратите внимание, что здесь я проиллюстрировал проблему с помощью конструктора, но вызов метода мог иметь такое же ограничение проверки нуля.
Учимся избегать null-значений в современном Java. Часть 2
Oct 13, 2020 · 8 min read
Возвращайте Optional вместо null
Хоть в предыдущей статье я и убеждал вас в уместности null для некоторых сценариев, в этой я буду напротив говорить, что по возможности его все же лучше избегать. При каждом добавлении в базу кода нового метода, способного вернуть пустое значение, вам следует стараться использовать вместо null тип Optional. Этот тип был введен, чтобы разработчики могли указывать на возможность возвращения методом пустого значения, что ранее было недоступно (либо требовало аннотаций, о которых я расскажу ниже). Существует два вида объектов Optional : содержащие значение и без него. Первые изначально создаются со значением, вторые же просто являются статическими одиночками. Структурно типичный случай их использования выглядит так:
Чтобы увидеть, почему сигнатура с Optional предпочтительней, представьте следующий метод:
Поскольку смысл использовать Optional есть только в случае возможного возврата пустого значения, значит метод такое значение вернуть может. Поэтому при каждом возвращении Optional методом вы знаете, что есть вероятность получения пустого значения и его нужно должным образом обработать.
Со значением Optional соответствующий код будет выглядеть так:
Однако если бы вместо этого у нас был метод, возвращающий активную госпитализацию, то предпочтительнее было бы использовать Optional :
Можно ли использовать Optional для параметров?
Никогда не делайте следующее, равно как не предоставляйте null в качестве аргумента параметра с Optional значением:
Если вы сделаете нечто подобное, то также получите NPE (исключение нулевого указателя).
Содействуйте IDE с помощью аннотаций Nullable/Nonnull
Вот один из примеров подобной сигнатуры метода:
Используйте Objects.requireNonNull()
Здесь у вас может возникнуть вопрос, заключается ли причина избегания нулевого параметра в том, что он может ненамеренно привести к NPE. Не будет ли лучше выбросить NPE намеренно до того, как это произойдет?
Скорее всего, это одно и то же, и с позиции пользователя выглядеть это будет тоже одинаково — в виде появления ошибки. А вот при диагностировании причины сбоя в дальнейшем, последний вариант окажется гораздо предпочтительнее. Проблема с NPE в том, что они не сообщают, какая переменная оказалась null, а просто предоставляют номер строки. В строке, где для объектов вызывается несколько методов, может быть сложно определить, в каком из них причина.
Предположим, вы получаете NPE в следующей строке кода:
Выбрасывание собственного исключения для пустого значения параметра будет тут же показывать в лог-файлах, где искать проблему, потому что на нее будет указывать ваше собственное сообщение об ошибке.
Работа со строками
Используйте класс Objects и библиотеку StringUtils
Ошибки нередко прокрадываются в базу кода, когда у нас нет ясного понимания того, что код делает или почему он это делает. Здесь важно удобство в обслуживании. Я часто сталкиваюсь с запутанным кодом создания строки. По какой-то причине люди склонны увлекаться тернарными выражениями, помещая их в другие выражения или вкладывая друг в друга. Это очень эффективно усложняет чтение и понимание простой логики.
Не так складно, как в примере с C#, но, на мой взгляд, намного надежнее, чем исходный пример, а значит и шанс появления ошибок при работе с кодом уже существенно меньше.
Используйте StringUtils для защиты String-методов от null
Заключение
Вкратце содержание рассмотренной серии статей можно выразить так:
10 способов эффективно справиться с Null в Java
Авторизуйтесь
10 способов эффективно справиться с Null в Java
Когда я только начал программировать на Java, Null очень быстро стал моим главным врагом. Сейчас я могу с уверенностью сказать, что битва между мной и Null с успехом завершилась. Большинство NullPointerExceptions случаются по неосторожности, и, чтобы помочь вам научиться справляться с ними, я подготовил небольшой список того, что я обычно делаю, когда встречаюсь Null.
Не усложняйте
Используйте методы Objects в качестве предикатов Stream
Хотя использование Objects.isNull и Objects.nonNull не очень хорошо подходит при обычной проверки на Null, однако они отлично подойдут для использования в потоках.
Никогда не передавайте Null в качестве аргумента
Данных проблем можно избежать, если никогда не использовать Null в качестве аргумента функции.
Проверяйте аргументы публичных API
Конечно, вы и ваша команда можете придерживаться принципа — «никогда не использовать Null в качестве аргумента функции», но что, если у вас есть свой публичный API, и его пользователи даже не слышали о таком принципе? Поэтому лучше всегда проверять на корректность аргументы, передаваемые в ваш API.
Эффективно используйте Optional
Возвращайте пустые коллекции вместо Null
Optional не подходит для полей
Согласно правилам инкапсуляции вы должны иметь полный контроль над значениями полей, включая Null. С другой стороны, что если мы сделаем так, что поля могут и не иметь значений? Тогда это приведет к нескольким проблемам:
Вывод: не используйте Optional с полями.
Используйте исключения вместо Null
Если что-то пошло не так: всегда используйте исключения, вместо того, чтобы возвращать Null.
Тестируйте свой код
Тестирование — хороший способ обнаружить NPE и исправить их. Поэтому никогда не стоит выпускать проект, предварительно не протестировав его.
Двойная проверка
Каждый раз, когда вы предполагаете, что какое-то выражение не может оказаться Null — дважды проверьте ваши выводы. Используйте документацию к API, спросите коллег, задайте вопрос на Stack Overflow. И всегда помните, что лучше перестраховаться, чем потом возиться с Null.