Как проверить на null java
Для проверки на null в Java вы можете использовать оператор сравнения == :
Object obj = null; if (obj == null) // ваш код. > Вы также можете использовать метод Objects.isNull() из класса java.util.Objects , который возвращает true , если переданный ему аргумент является null :
Object obj = null; if (Objects.isNull(obj)) // ваш код. > 9 вещей о NULL в Java
Java и null неразрывно связаны. Едва ли существует Java-программист, не встречавшийся с «null pointer exception» и это печальный факт. Даже изобретатель концепции «null» назвал ее своей ошибкой на миллиард долларов, тогда зачем Java поддерживает ее? null был здесь долгое время, и я полагаю, создатели Java знают, что он создает больше проблем чем решает, так почему же они все еще мирятся с этим. И это удивляет меня еще больше, потому что философией Java было упростить вещи, вот почему они больше не возятся с указателями, перегрузкой операторов и множественным наследованием, но почему null?Ну, я действительно не знаю ответ на этот вопрос, но, что я точно знаю, не имеет значения сколько бы null критиковался Java-программистами и open-source сообществом, мы должны жить с ним. Вместо того чтобы сожалеть, лучше узнать больше и быть уверенным что мы используем null правильно.
Почему Вы должны узнать о null в Java?
Потому что, если Вы не обратите внимания на null, будьте уверены, Java заставит страдать от ужасного java.lang.NullPointerException и Вы выучите этот урок, но пойдете более трудным путем. Написание устойчивого к «падениям» кода — это искусство и Ваша команда, заказчики и пользователи оценят это. По моему опыту, одна из основных причин NullPointerException это недостаток знаний о null в Java. Многие из Вас уже знакомы с null, остальные смогу узнать некоторые старые и новые вещи о ключевом слове null. Давайте повторим или узнаем некоторые важные вещи о null в Java.
Что есть null в Java
- Перво-наперво, null это ключевое слово в Java, так же как public , static или final . Регистр учитывается, Вы не можете писать null как Null или NULL, компилятор не распознает его и будет выброшена ошибка.
Object obj = NULL; // Not Ok Object obj1 = null //Ok
private static Object myObj; public static void main(String args[]) < System.out.println("What is value of myObjc : " + myObj); >What is value of myObjc : null
String str = null; // null can be assigned to String Integer itr = null; // you can assign null to Integer also Double dbl = null; // null can also be assigned to Double String myStr = (String) null; // null can be type cast to String Integer myItr = (Integer) null; // it can also be type casted to Integer Double myDbl = (Double) null; // yes it's possible, no error
int i = null; // type mismatch : cannot convert from null to int short s = null; // type mismatch : cannot convert from null to short byte b = null: // type mismatch : cannot convert from null to byte double d = null; //type mismatch : cannot convert from null to double Integer itr = null; // this is ok int j = itr; // this is also ok, but NullPointerException at runtime
Integer iAmNull = null; int i = iAmNull; // Remember - No Compilation Error
Но, когда Вы запустите данный фрагмент кода, в консоли Вы увидите
Exception in thread "main" java.lang.NullPointerException
Это часто происходит при работе с HashMap и Integer key . Выполнение кода, показанного ниже прервется, как только Вы его запустите.
import java.util.HashMap; import java.util.Map; /** * An example of Autoboxing and NullPointerExcpetion * * @author WINDOWS 8 */ public class Test < public static void main(String args[]) throws InterruptedException < Map numberAndCount = new HashMap<>(); int[] numbers = ; for(int i : numbers) < int count = numberAndCount.get(i); numberAndCount.put(i, count++); // NullPointerException here >> >
Output: Exception in thread "main" java.lang.NullPointerException at Test.main(Test.java:25)
Integer iAmNull = null; if(iAmNull instanceof Integer)< System.out.println("iAmNull is instance of Integer"); >else
Output : iAmNull is NOT an instance of Integer
public class Testing < public static void main(String args[])< Testing myObject = null; myObject.iAmStaticMethod(); myObject.iAmNonStaticMethod(); >private static void iAmStaticMethod() < System.out.println("I am static method, can be called by null reference"); >private void iAmNonStaticMethod() < System.out.println("I am NON static method, don't date to call me by null"); >>
Output: I am static method, can be called by null reference Exception in thread "main" java.lang.NullPointerException at Testing.main(Testing.java:11)
public void print(Object obj)
может быть вызван как
print(null)
public class Test < public static void main(String args[]) throws InterruptedException < String abc = null; String cde = null; if(abc == cde)< System.out.println("null == null is true in Java"); >if(null != null) < System.out.println("null != null is false in Java"); >// classical null check if(abc == null) < // do something >// not ok, compile time error if(abc > null) < >> >
Output: null == null is true in Java
Java Optional не такой уж очевидный
NullPointerException — одна из самых раздражающих вещей в Java мире, которую был призван решить Optional . Нельзя сказать, что проблема полностью ушла, но мы сделали большие шаги. Множество популярных библиотек и фреймворков внедрили Optional в свою экосистему. Например, репозитории в Spring Data возвращают Optional вместо null .
Я думаю, что некоторые программисты настолько впечатлились теми возможностями, которые предоставляет Optional , что они стали использовать его даже там, где это не нужно, зачастую применяя неправильные паттерны. В этой статье я привел некоторые ошибочные использования этой монады и предложил свой путь для решения возникших проблем.
Optional не должен равняться null
Мне кажется, никаких дополнительных объяснений здесь не требуется. Присваивание null в Optional разрушает саму идею его использования. Никто из пользователей вашего API не будет проверять Optional на эквивалентность с null . Вместо этого следует использовать Optional.empty() .
Знайте API
Optional обладает огромным количеством фичей, правильное использование которых позволяет добиться более простого и понятного кода.
public String getPersonName() < Optionalname = getName(); if (name.isPresent()) < return name.get(); >return "DefaultName"; >Идея проста: если имя отсутствует, вернуть значение по умолчанию. Можно сделать это лучше.
public String getPersonName() < Optionalname = getName(); return name.orElse("DefautName"); >Давайте рассмотрим что-нибудь посложнее. Предположим, что мы хотим вернуть Optional от имени пользователя. Если имя входит в список разрешенных, контейнер будет хранить значение, иначе — нет. Вот многословный пример.
public Optional getPersonName() < Person person = getPerson(); if (ALLOWED_NAMES.contains(person.getName())) < return Optional.ofNullable(person.getName()); >return Optional.empty(); >Optional.filter упрощает код.
public Optional getPersonName()
Этот подход стоит применять не только в контексте Optional , но ко всему процессу разработки.
Если что-то доступно из коробки, попробуйте использовать это, прежде чем пытаться сделать свое.
Отдавайте предпочтение контейнерам «на примитивах»
В Java присутствуют специальные не дженерик Optional классы: OptionalInt , OptionalLong и OptionalDouble . Если вам требуется оперировать примитивами, лучше использовать вышеописанные альтернативы. В этом случае не будет лишних боксингов и анбоксингов, которые могут повлиять на производительность.
Не пренебрегайте ленивыми вычислениями
Optional.orElse — это удобной инструмент для получения значения по умолчанию. Но если его вычисление является дорогой операцией, это может повлечь за собой проблемы с быстродействием.
public Optional retrieveTable()
Даже если таблица присутствует в кэше, значение с удаленного сервера будет запрашиваться при каждом вызове метода. К счастью, есть простой способ избежать этого.
public Optional retrieveTable()
Optional.orElseGet принимает на вход лямбду, которая будет вычислена только в том случае, если метод был вызван на пустом контейнере.
Не оборачивайте коллекции в Optional
Хотя я и видел такое не часто, иногда это происходит.
public Optional> getNames() < if (isDevMode()) < return Optional.of(getPredefinedNames()); >try < Listnames = getNamesFromRemote(); return Optional.of(names); > catch (Exception e) < log.error("Cannot retrieve names from the remote server", e); return Optional.empty(); >>Любая коллекция является контейнером сама по себе. Для того чтобы показать отсутствие элементов в ней, не требуется использовать дополнительные обертки.
public List getNames() < if (isDevMode()) < return getPredefinedNames(); >try < return getNamesFromRemote(); >catch (Exception e) < log.error("Cannot retrieve names from the remote server", e); return emptyList(); >>Чрезмерное использование Optional усложняет работу с API.
Не передавайте Optional в качестве параметра
А сейчас мы начинаем обсуждать наиболее спорные моменты.
Почему не стоит передавать Optional в качестве параметра? На первый взгляд, это позволяет избежать NullPointerException , так ведь? Возможно, но корни проблемы уходят глубже.
public void doAction() < OptionalInt age = getAge(); Optionalrole = getRole(); applySettings(name, age, role); >Во-первых, API имеет ненужные границы. При каждом вызове applySettings пользователь вынужден оборачивать значения в Optional . Даже предустановленные константы.
Во-вторых, applySettings обладает четырьмя потенциальными поведениями в зависимости от того, являются ли переданные Optional пустыми, или нет.
В-третьих, мы понятия не имеем, как реализация интерпретирует Optional . Возможно, в случае пустого контейнера происходит простая замена на значение по умолчанию. Может быть, выбрасывается NoSuchElementException . Но также вероятно, что наличие или отсутствие данных в монаде может полностью поменять бизнес-логику.
Если взглянуть на javadoc к Optional , можно найти там интересную заметку.
Optional главным образом предназначен для использования в качестве возвращаемого значения в тех случаях, когда нужно отразить состояние «нет результата» и где использование null может привести к ошибкам.
Optional буквально символизирует нечто, что может содержать значение, а может — нет. Передавать возможное отсутствие результата в качестве параметра звучит как плохая идея. Это значит, что API знает слишком много о контексте выполнения и принимает те решения, о которых не должен быть в курсе.
Что же, как мы можем улучшить этот код? Если age и role должны всегда присутствовать, мы можем легко избавиться от Optional и решать проблему отсутствующих значений на верхнем уровне.
public void doAction() < OptionalInt age = getAge(); Optionalrole = getRole(); applySettings(name, age.orElse(defaultAge), role.orElse(defaultRole)); >Теперь вызывающий код полностью контролирует значения аргументов. Это становится еще более критичным, если вы разрабатываете фреймворк или библиотеку.
С другой стороны, если значения age и role могут быть опущены, вышеописанный способ не заработает. В этом случае лучшим решением будет разделение API на отдельные методы, удовлетворяющим разным пользовательским потребностям.
void applySettings(String name) < . >void applySettings(String name, int age) < . >void applySettings(String name, Role role) < . >void applySettings(String name, int age, Role role)
Возможно это выглядит несколько многословно, но теперь пользователь может сам решить, какой метод вызвать, избегая непредвиденных ошибок.
Не используйте Optional в качестве полей класса
Я слышал разные мнения по этому вопросу. Некоторые считают, что хранение Optional напрямую в полях класса позволяет сократить NullPointerException на порядок. Мой друг, который работает в одном известном стартапе, говорит, что такой подход в их компании является утвержденным паттерном.
Хотя хранение Optional в полях класса и звучит как хорошая идея, я думаю, что это может принести больше проблем, чем пользы.
Отсутствие сериализуемости
Optional не имлементирует интерфейс Serializable . Это не баг, это намеренное решение, так как данный класс был спроектирован для использования в качестве возвращаемого значения. Проще говоря, любой объект, который содержит хотя бы одно Optional поле, нельзя сериализовать.
На мой взгляд, этот аргумент является наименее убедительным, так как сейчас, в мире микросервисов и распределенных систем, платформенная сериализация не является настолько важной, как раньше.
Хранение лишних ссылок
Optional — это объект, который необходим пользователю всего несколько миллисекунд, после чего он может быть безболезненно удален сборщиком мусора. Но если мы храним Optional в качестве поля, он может оставаться там вплоть до самой остановки программы. Скорее всего, вы не заметите никаких проблем с производительностью на маленьких приложениях. Однако, если речь идет о большом сервисе с дюжинами бинов, последствия могут быть другие.
Плохая интеграция со Spring Data/Hibernate
Предположим, что мы хотим построить простое Spring Boot приложение. Нам нужно получить данные из таблицы в БД. Сделать это очень просто, объявив Hibernate сущность и соответствующий репозиторий.
@Entity @Table(name = «person») public class Person < @Id private long id; @Column(name = "firstname") private String firstName; @Column(name = "lastname") private String lastName; // constructors, getters, toString, and etc. >public interface PersonRepository extends JpaRepository
Вот возможный результат для personRepository.findAll() .
Person(id=1, firstName=John, lastName=Brown) Person(id=2, firstName=Helen, lastName=Green) Person(id=3, firstName=Michael, lastName=Blue)Пусть поля firstName и lastName могут быть null . Мы не хотим иметь дело с NullPointerException , так что просто заменим обычный тип поля на Optional .
@Entity @Table(name = "person") public class Person < @Id private long id; @Column(name = "firstname") private OptionalfirstName; @Column(name = "lastname") private Optional lastName; // constructors, getters, toString, and etc. >Теперь все сломано.
org.hibernate.MappingException: Could not determine type for: java.util.Optional, at table: person, for columns: [org.hibernate.mapping.Column(firstname)]Hibernate не может замапить значения из БД на Optional напрямую (по крайней мере, без кастомных конвертеров).
Но некоторые вещи работают правильно
Должен признать, что в конечном итоге не все так плохо. Некоторые фреймворки корректно интегрируют Optional в свою экосистему.
Jackson
Давайте объявим простой эндпойнт и DTO.
public class PersonDTO < private long id; private String firstName; private String lastName; // getters, constructors, and etc. >@GetMapping("/person/") public PersonDTO getPersonDTO(@PathVariable long id) < return personRepository.findById(id) .map(person ->new PersonDTO( person.getId(), person.getFirstName(), person.getLastName()) ) .orElseThrow(); >Результат для GET /person/1 .
Как вы можете заметить, нет никакой дополнительной конфигурации. Все работает из коробки. Давайте попробуем заменить String на Optional .
public class PersonDTO < private long id; private OptionalfirstName; private Optional lastName; // getters, constructors, and etc. >Для того чтобы проверить разные варианты работы, я заменил один параметр на Optional.empty() .
@GetMapping("/person/") public PersonDTO getPersonDTO(@PathVariable long id) < return personRepository.findById(id) .map(person ->new PersonDTO( person.getId(), Optional.ofNullable(person.getFirstName()), Optional.empty() )) .orElseThrow(); >Как ни странно, все по-прежнему работает так, как и ожидается.
Это значит, что мы можем использовать Optional в качестве полей DTO и безопасно интегрироваться со Spring Web? Ну, вроде того. Однако есть потенциальные проблемы.
SpringDoc
SpringDoc — это библиотека для Spring Boot приложений, которая позволяет автоматически сгенерировать Open Api спецификацию.
Вот пример того, что мы получим для эндпойнта GET /person/ .
"PersonDTO": < "type": "object", "properties": < "id": < "type": "integer", "format": "int64" >, "firstName": < "type": "string" >, "lastName": < "type": "string" >> >Выглядит довольно убедительно. Но нам нужно сделать поле id обязательным. Это можно осуществить с помощью аннотации @NotNull или @Schema(required = true) . Давайте добавим кое-какие детали. Что если мы поставим аннотацию @NotNull над полем типа Optional ?
public class PersonDTO < @NotNull private long id; @NotNull private OptionalfirstName; private Optional lastName; // getters, constructors, and etc. >Это приведет к интересным результатам.
"PersonDTO": < "required": [ "firstName", "id" ], "type": "object", "properties": < "id": < "type": "integer", "format": "int64" >, "firstName": < "type": "string" >, "lastName": < "type": "string" >> >Как видим, поле id действительно добавилось в список обязательных. Так же, как и firstName . А вот здесь начинается самое интересное. Поле с Optional не может быть обязательным, так как само его наличие говорит о том, что значение потенциально может отсутствовать. Тем не менее, мы смогли запутать фреймворк с помощью всего лишь одной лишней аннотации.
В чем здесь проблема? Например, если кто-то на фронтенде использует генератор типов сущностей по схеме Open Api, это приведет к получению неверной структуры, что в свою очередь может привести к повреждению данных.
Решение
Что же нам делать со всем этим? Ответ прост. Используйте Optional только для геттеров.
public class PersonDTO < private long id; private String firstName; private String lastName; public PersonDTO(long id, String firstName, String lastName) < this.id = id; this.firstName = firstName; this.lastName = lastName; >public long getId() < return id; >public Optional getFirstName() < return Optional.ofNullable(firstName); >public Optional getLastName() < return Optional.ofNullable(lastName); >>Теперь этот класс можно безопасно использовать и как сущность Hibernate, и как DTO. Optional никак не влияет на хранимые данные. Он только оборачивает возможные null , чтобы корректно отрабатывать отсутствующие значения.
Однако у этого подхода есть один недостаток. Его нельзя полностью интегрировать с Lombok. Optional getters не подерживаются библиотекой и, судя по некоторым обсуждениям на Github, не будут.
Я писал статью по Lombok и я думаю, что это прекрасный инструмент. Тот факт, что он не интегрируются с Optional getters , довольно печален.
На текущий момент единственным выходом является ручное объявление необходимых геттеров.
Заключение
Это все, что я хотел сказать по поводу java.util.Optional . Я знаю, что это спорная тема. Если у вас есть какие-то вопросы или предложения, пожалуйста, оставляйте свои комментарии. Спасибо за чтение!
Как общаться с null в Java и не страдать
Java и null неразрывно связаны. Трудно найти Java-программиста, который не сталкивался с NullPointerException . Если даже автор понятия нулевого указателя признал его «ошибкой на миллиард долларов», почему он сохранился в Java? null присутствует в Java уже давно, и я уверен, что разработчики языка знают, что он создает больше проблем, чем решает. Это удивительно, ведь философия Java — делать вещи как можно более простыми. Если разработчики отказались от указателей, перегрузки операторов и множественного наследования, то почему они оставили null ? Я не знаю ответа на этот вопрос. Однако не имеет значения, насколько много критики идет в адрес null в Java, нам придется с этим смириться. Вместо того, чтобы жаловаться, давайте лучше научимся правильно его использовать. Если быть недостаточно внимательным при использовании null , Java заставит вас страдать с помощью ужасного java.lang.NullPointerException . Наиболее частая причина NullPointerException — недостаточное понимание тонкостей использования null . Давайте вспомним самые важные вещи о нем в Java.
Что такое null в Java
Как мы уже выяснили, null очень важен в Java. Изначально он служил, чтобы обозначить отсутствие чего-либо, например, пользователя, ресурса и т. п. Но уже через год выяснилось, что он приносит много проблем. В этой статье мы рассмотрим основные вещи, которые следует знать о нулевом указателе в Java, чтобы свести к минимуму проверки на null и избежать неприятных NullPointerException .
1. В первую очередь, null — это ключевое слово в Java, как public , static или final . Оно регистрозависимо, поэтому вы не сможете написать Null или NULL , компилятор этого не поймет и выдаст ошибку:
Object obj1 = NULL; // Неверно Object obj2 = null; // ОК Эта проблема часто возникает у программистов, которые переходят на Java с других языков, но с современными средами разработки это несущественно. Такие IDE, как Eclipse или Netbeans, исправляют эти ошибки, пока вы набираете код. Но во времена Блокнота, Vim или Emacs это было серьезной проблемой, которая отнимала много времени.
2. Так же, как и любой примитивный тип имеет значение по умолчанию (0 у int , false у boolean ), null — значение по умолчанию любого ссылочного типа, а значит, и для любого объекта. Если вы объявляете булеву переменную, ей присваивается значение false . Если вы объявляете ссылочную переменную, ей присваивается значение null , вне зависимости от области видимости и модификаторов доступа. Единственное, компилятор предупредит о попытке использовать неинициализированную локальную переменную. Для того, чтобы убедиться в этом, вы можете создать ссылочную переменную, не инициализируя ее, и вывести ее на экран:
private static Object myObj; public static void main(String args[]) < System.out.println("Значение myObj : " + myObj); >// Значение myObjc: null Это справедливо как для статических, так и для нестатических переменных. В данном случае мы объявили myObj как статическую переменную для того, чтобы ее можно было использовать в статическом методе main .
3. Несмотря на распространенное мнение, null не является ни объектом, ни типом. Это просто специальное значение, которое может быть присвоено любому ссылочному типу. Кроме того, вы также можете привести null к любому ссылочному типу:
String str = null; // null можно присвоить переменной типа String, . Integer itr = null; // . и Integer, . Double dbl = null; // . и Double. String myStr = (String) null; // null может быть приведен к String . Integer myItr = (Integer) null; // . и к Integer Double myDbl = (Double) null; // без ошибок. Как видите, приведение null к ссылочному типу не вызывает ошибки ни при компиляции, ни при запуске. Также при запуске не будет NullPointerException , несмотря на распространенное заблуждение.
4. null может быть присвоен только переменной ссылочного типа. Примитивным типам — int , double , float или boolean — значение null присвоить нельзя. Компилятор не допустит этого и выдаст ошибку:
int i = null; // type mismatch: cannot convert from null to int short s = null; // type mismatch: cannot convert from null to short byte b = null: // type mismatch: cannot convert from null to byte double d = null; // type mismatch: cannot convert from null to double Integer itr = null; // все в порядке int j = itr; // нет ошибки при компиляции, но NullPointerException при запуске Итак, попытка присвоения значения null примитивному типу — ошибка времени компиляции, но вы можете присвоить null типу-обертке, а затем присвоить это значение соответствуему примитиву. Компилятор ругаться не будет, но при выполнении кода будет брошено NullPointerException . Это происходит из-за автоматического заворачивания (autoboxing) в Java
5. Любой объект класса-обертки со значением null кинет NullPointerException при разворачивании (unboxing). Некоторые программисты думают, что обертка автоматически присвоит примитиву значение по умолчанию (0 для int , false для boolean и т. д.), но это не так:
Integer iAmNull = null; int i = iAmNull; // компиляция пройдет успешно Если вы запустите этот код, вы увидите Exception in thread «main» java.lang.NullPointerException в консоли. Это часто случается при работе с HashMap с ключами типа Integer . Код ниже сломается, как только вы его запустите:
import java.util.HashMap; import java.util.Map; public class Test < public static void main(String args[]) throws InterruptedException < MapnumberAndCount = new HashMap<>(); int[] numbers = ; for (int i : numbers) < int count = numberAndCount.get(i); // NullPointerException numberAndCount.put(i, count++); >> > Exception in thread "main" java.lang.NullPointerException at Test.main(Test.java:14) Этот код выглядит простым и понятным. Мы ищем, сколько каждое число встречается в массиве, это классический способ поиска дубликатов в массиве в Java. Мы берем предыдущее значение количества, инкрементируем его и кладем обратно в HashMap . Мы полагаем, что Integer позаботится о том, чтобы вернуть значение по умолчанию для int , однако если числа нет в HashMap , метод get() вернет null , а не 0. И при оборачивании выбросит NullPoinerException . Представьте, что этот код завернут в условие и недостаточно протестирован. Как только вы его запустите на продакшен – УПС!
6. Оператор instanceof вернет false , будучи примененным к переменной со значением null или к литералу null :
Integer iAmNull = null; if (iAmNull instanceof Integer) < System.out.println("iAmNull — экземпляр Integer"); >else
iAmNull не является экземпляром Integer Это важное свойство оператора instanceof , которое делает его полезным при приведении типов.
7. Возможно, вы уже знаете, что если вызвать нестатический метод по ссылке со значением null , результатом будет NullPointerException . Но зато вы можете вызвать по ней статический метод класса:
public class Testing < public static void main(String args[])< Testing myObject = null; myObject.iAmStaticMethod(); myObject.iAmNonStaticMethod(); >private static void iAmStaticMethod() < System.out.println("I am static method, can be called by null reference"); >private void iAmNonStaticMethod() < System.out.println("I am NON static method, don't date to call me by null"); >> Результат выполнения этого кода:
I am static method, can be called by null reference Exception in thread "main" java.lang.NullPointerException at Testing.main(Testing.java:5) 8. Вы можете передавать null в любой метод, который принимает ссылочный тип, например, public void print(Object obj) может быть вызван так: print(null) . С точки зрения компилятора ошибки здесь нет, но поведение такого кода целиком зависит от реализации метода. Безопасный метод не кидает NullPointerException в этом случае, а тихо завершает работу. Если бизнес-логика позволяет, лучше писать безопасные методы.
9. Вы можете сравнивать null , используя оператор == («равно») и != («не равно»), но не с арифметическими или логическими операторами (такими как «больше» или «меньше»). В отличие от SQL, в Java null == null вернет true :
public class Test < public static void main(String args[]) throws InterruptedException < String abc = null; String cde = null; if (abc == cde) < System.out.println("null == null is true in Java"); >if (null != null) < System.out.println("null != null is false in Java"); >// classical null check if (abc == null) < // do something >// not ok, compile time error if (abc > null) < // do something >> > Вывод этого кода:
null == null is true in Java Вот и все, что надо знать о null в Java. При наличии небольшого опыта и с помощью простых приемов вы можете сделать свой код безопасным. Поскольку null может рассматриваться как пустая или неинициализированная переменная, важно документировать поведение метода при получении null . Помните, что любая созданная и не проинициализированная переменная имеет по умолчанию значение null и что вы не можете вызвать метод объекта или обратиться к его полю, используя null .
Перевод статьи «9 Things about Null in Java»
Следите за новыми постами по любимым темам
Подпишитесь на интересующие вас теги, чтобы следить за новыми постами и быть в курсе событий.