Ошибка на миллиард долларов java - ErrorsMaster.ru - большая энциклопедия ошибок и их решений

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 {

        Map<Integer, Integer> numberAndCount = new HashMap<>();

        int[] numbers = {3, 5, 7, 9, 11, 13, 17, 19, 2, 3, 5, 33, 12, 5};

        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 {
    System.out.println("iAmNull не является экземпляром Integer");
}

Результат выполнения:

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»}

Java

В своем выступлении “Null References: The billion dollar mistake” (“Нулевые ссылки: ошибка на миллиард долларов”), Тони Хоар описывает реализацию нулевых ссылок в языках программирования ALGOL, что также по его словам стало ошибкой стоимостью в миллиард долларов. Такие авторитетные книги, как Clean Code: A Handbook of Agile Software Craftsmanship (“Чистый код: настольное руководство по гибкой разработке ПО”) рекомендуют использовать нуль как можно реже. В то же время в книге Bug Patterns in Java (“Шаблоны ошибок в Java”) проблемам, связанным с нулевыми значениями, посвящается аж целых три главы. Тема “What is a null pointer exception and how do I fix it” (“Что такое исключение нулевого значения и как его исправить”), обсуждаемая на Stack Overflow, набрала уже более 3 млн просмотров. Работа с нулевыми значениями и впрямь может вызвать немало сложностей.

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

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

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

Чем опасен null?

Null — это особое значение, поскольку оно не ассоциируется ни с каким типом (можете смело проверить это инструкцией instanceofв отношении любого другого класса в JRE) и с радостью занимает место любого другого объекта в присвоениях переменных и вызовах методов. Именно в этом и кроются две основных его опасности:

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

В результате любое возвращаемое значение или объект параметра — это потенциальное исключение нулевого указателя (NPE), возникающее в случае неправильной обработки.

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

Может тогда вообще никогда не присваивать значениям null? Тоже неудачное предположение. Если учесть тот факт, что в каждом языке программирования есть пустое значение (nil, undefined, None, void и т.д.), то наличие общего значения, обозначающего отсутствие чего-либо, чрезвычайно полезно.

Ошибка в условии цикла while может породить бесконечный цикл в любой программе, но это не делает такие циклы плохими по природе. Аналогично будет неверным считать, что null всегда неуместен только из-за того, что его неправильное использование может привести к ошибкам. Null — это наиболее естественное значение для выражения конкретных вещей, но при этом очень неподходящее для выражения других. Компетентные разработчики должны уметь различать эти случаи. В следующем разделе я как раз перейду к объяснению этого.

Когда Null уместен, а когда нет

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

Возвращение null

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

Сейчас я работаю над проектом электронной записи пациентов Columna, в котором у нас есть классы, представляющие элементы рабочего процесса больницы вроде пациентов, медикаментов, врачей, больничных отделений, госпитализаций и пр. При моделировании любой области возникают случаи, когда нам нужно допустить для определенного элемента отсутствие значения. Предположим, что у нас есть класс, представляющий госпитализацию с атрибутами, которые ее описывают: больничное отделение, куда помещается пациент, причина госпитализации, ее время и т.д. Аналогичным образом у нас может быть класс, который представляет пациента с набором атрибутов вроде имени и номера социального страхования. В любой момент времени пациент может быть госпитализирован или нет. Говоря более формально, у нас есть связь типа “имеет” с мощностью 0..1.

Представим метод, извлекающий из базы данных информацию о госпитализации данного пациента:

public Admission getAdmission(Patient patient);

Что должен возвращать этот метод для не госпитализированного пациента, если не null? Есть ли для выражения этого более точное значение? Спорю, что нет.

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

Некоторые выступают за использование так называемого шаблона проектирования Null Object вместо null. Главная его идея в реализации пустого класса с минимумом или вообще без функциональности, т.е. нулевого объекта, который можно использовать вместо класса, содержащего действительную функциональность. Лучше всего данный шаблон показывает себя в сценариях, где нужно рекурсивно обойти структуру бинарного дерева в поиске суммы значений всех узлов. Для этого вы выполняете поиск в глубину и рекурсивно суммируете в каждом узле значения его левого и правого поддерева.

Дерево поиска обычно реализуется так, что каждый узел в нем имеет левого и правого потомка, которые являются либо также узлами, либо концевыми вершинами. Если такое представление дерева использует для концевых узлов null, то вам придется явно выполнять проверки на нулевых потомков, чтобы останавливать рекурсию в концевом узле, предотвращая попытку получения его значения. Вместо этого вам следует определить интерфейс Node с простым методом getValue() и реализовать его в представляющем узел классе, который вычисляет значение, складывая значения getValues() потомков, как показано на рисунке ниже. Реализуйте такой же интерфейс в классе, представляющем узел, и пусть класс концевого узла возвращает при вызове 0. Теперь нам больше не нужно различать код между концевым узлом и обычным. Необходимость явно проверять наличие null отпала вместе с риском получения исключения (NPE).

Применение шаблона нулевого объекта к структуре дерева

Для применения этого шаблона к примеру с госпитализацией нам потребуется создать интерфейс Admission. Затем мы определим класс AdmissionImpl для случаев, когда мы можем вернуть данные фактической госпитализации и класс AdmissionNullObjectImpl для случаев, когда не можем. Это позволит методу getAdmission() возвращать либо реальный AdmissionImpl, либо AdmissionNullObjectImpl. Так как вызывающий код использует общий тип Admission, мы можем рассматривать оба объекта одинаково, не рискуя получить исключение и не загромождая код проверками обработки null.

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

Что будет возвращать класс AdmissionNullObject, когда в нем нет данных? Что он должен возвращать вместо объекта локации, когда вызывается getLocation()? Какой будет подходящая начальная дата для возврата?

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

Еще одна альтернатива — это использовать вместо null пустую string, если атрибутом является простая строка. Это избавляет нас от риска получить NPE, но при этом для правильной обработки пустого значения, скорее всего, потребуется столько же проверок, как и в случае с null. Кроме того, семантика будет отличаться: пустая строка представляет строку с пустым значением, а null не представляет ничего. Это становится актуальным, когда приложению нужно различать, ввел пользователь информацию в виде значения пустой строки или нет. Вы избавляетесь от риска получить NPE ценой применения несколько сбивающего с толку значения.

Теперь давайте рассмотрим применение null в коде, не моделирующем реальные концепции. Большинство классов в базе объектно-ориентированного кода не имеют соответствий в реальной жизни и существуют только в виде абстракции инфраструктуры, обработки и преобразования, а также для группировки связанной функциональности. При этом не до конца понятно, должно ли допускаться их представление нулевым значением. Если мы вызываем геттер для значения с очень абстрактным типом вроде TwoFactorComplexStrategyHandlerDelegateBean, стоит ли нам ожидать, что оно будет null?

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

Такие объекты де факто не должны быть представлены нулевым значением. Не только в нашей базе кода, но также и в JRE, библиотеках и фреймворках. Это можно назвать проблематичным, но вопрос насколько? Важно понимать, что несмотря на необходимость минимизировать использование null, мы не должны добиваться этого ценой переполнения баз кода сложными обходными маневрами с целью избежать появления таких значений. Как я уже отмечал, альтернативы в данном случае не всегда хороши. Однако есть случаи возвращения null, которых избежать легко, хотя встречаются они частенько. Возвращение null для классов в таких ситуациях вызывает подозрение. Например, иногда null возвращается из методов геттеров, где объект не может быть создан по определенным причинам вроде ошибки сервера при его вызове методом. Этот метод обрабатывает ошибку, регистрируя ее в инструкцию catch, и вместо создания экземпляра объекта возвращает null. Это легко исправить. Исключение должно использоваться для указания на неполадку и привлекать для ее обработки вызывающий код. Возвращение null в подобных сценариях будет сбивать с толку, не обеспечит обработку ошибки и может перенести проблему в другую часть кода, где было бы лучше использовать систему fail-fast, немедленно останавливающую работу приложения в случае потенциального сбоя.

Еще одно ошибочное использование null — это представление связи “имеет” с мощностью 0..* (в начале статьи я говорил о связях 0..1). Если вернуться к примеру с объектом пациента, то в нем пациент может иметь одного/нескольких зарегистрированных родственников или не иметь их совсем. Тем не менее я часто вижу, что люди возвращают null, когда для заполнения списка или других типов коллекций нет данных. Аналогичным образом null в качестве аргумента используется в методах для замещения отсутствующих коллекций. Но его применение в данном случае нежелательно по ряду причин. Он сбивает с толку, поскольку коллекцией мощность связи представляется идеально, а присвоив null типу коллекции, вы только добавляете ненужные риски в код. Цикл for, основанный на коллекции, ничего не делает, если эта коллекция пуста. В противном же случае он перебирает каждый элемент, выполняя определенные действия. Если вы позволите коллекции быть null, то выразите, по сути, пустой список, означающий, что в нем обрабатывать нечего. Однако при этом вам придется обеспечить выполнение проверки на null для каждого последующего метода, использующего эту коллекцию, иначе может возникнуть NPE. В случаях, когда нет данных для представления — вызывайте методы с пустыми коллекциями. Это также легко, как вызвать Collections.emptyList(), emptyMap(), emptySet() и т.д. Ненамного больше работы, чем объявить null, зато намного лучше.

Передача нулевых параметров

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

Как же полностью избежать нулевых параметров?

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

В таких языках, как Python, сигнатуры методов могут содержать предустановленные значения параметров, используемые при отсутствии значения аргумента в вызове метода. Тем не менее в Java такое невозможно. Ближайшим аналогом этого будет использовать перегрузку метода, когда в классе одна и та же сигнатура метода определяется несколько раз с разными параметрами. Один метод будет содержать всю функциональность и принимать весь набор параметров, а другие будут просто “декораторами” для вызова этого метода, каждый из которых будет получать свой поднабор параметров. Методы-декораторы определяют, какие значения должны использовать вместо отсутствующих параметров, чтобы вызывающему компоненту не пришлось их предоставлять. Жестко прописывая, какие значения должны предоставляться, когда у вызывающего их не хватает, мы уменьшаем риск появления ошибок и делаем принимаемые значения параметров явными.

Аналогичным образом можно разбирать конструкторы, но также можно использовать шаблон строитель. Он помогает минимизировать число параметров конструктора и удаляет необходимость передавать в него нулевые значения, предоставляя для создания класса объект Builder. Смысл данного шаблона в косвенном инстанцировании объекта через промежуточный класс builder. Для предоставления аргументов, которые вы могли бы передать в конструктор напрямую, вы вызываете соответствующий каждому сеттер. Если значение еще не было установлено, builder предоставит его. Затем вы вызываете для builder метод Create(), и он инстанцирует объект за вас. Как и в большинстве шаблонов, в строителе вводятся дополнительные классы и сложность, поэтому прежде, чем его использовать, убедитесь, что в этом есть смысл. Использование его только ради избежания вызова конструктора с парой нулевых значения, скорее всего, будет излишним.

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

Воспринимайте null правильно

Все больше языков программирования начинают реализовывать определенные возможности с учетом безопасности. Например, в таких языках, как Clojure, F# и Rust переменные по умолчанию неизменяемы. Компилятор допускает изменение значений только для тех из них, которые объявлены со специальным модификатором. Такой способ использования опасных функций вынуждает программистов переопределять поведение по умолчанию, указывая тем самым, что они осознают степень риска и делают это не без весомых оснований. И к null нам стоит относиться аналогичным образом. Нужно придерживать это значение для особых случаев, где оно будет вполне уместно, ограничив при этом его использование в целом, опять же не ценой усложнения кода креативными обходными решениями. При каждом намерении использовать null вместо перемещающегося между методами значения следует учесть оправданность этого. В таком случае вы должны гарантировать, что в итоге оно не окажется в том месте, где может вызвать проблемы, и другие разработчики будут знать, что значение может быть null. Если же этого обеспечить нельзя, то лучше рассмотреть другие варианты.

Что не так с NULL?

Проще говоря: NULL — это значение, которое не является значением. Вот и проблема.

Эта проблема усугубилась в самом популярном языке всех времен, и теперь у него много имен: NULL, nil, null, None, Nothing, Nil и nullptr. У каждого языка есть свои нюансы.

Некоторые из проблем, вызванных NULL, связаны только с конкретным языком, в то время как другие универсальны; некоторые — просто разные аспекты проблемы.

NULL…

Тип Subversion
Это грязно
Это особый случай
Сделать API хуже
Сделать неправильные языковые решения хуже
Сложно отлаживать
Не сочетается

1. Тип подрывной деятельности NULL

Статически типизированные языки могут проверять использование типов в программе без фактического выполнения программы и обеспечивать определенные гарантии поведения программы.

Например, в Java, если я напишуx.toUppercase(), Компилятор проверитx тип. в случае x Является String, То проверка типа прошла успешно; еслиx Является Socket, Тогда проверка типа не удалась.

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

toUppercase()Может быть произвольноStringВызов объекта. Пока неStringНулевой.
read()Может быть произвольноInputStreamВызов объекта. Пока неInputStreamНулевой.
toString()Может быть произвольноObjectВызов объекта. Пока неObjectНулевой.

Java — не единственный язык, вызывающий эту проблему; многие другие системы типов имеют те же недостатки, включая, конечно, язык AGOL W.

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

2. NULL беспорядочный

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

Программисты на Java пишут о риске синдрома запястного канала

if (str == null || str.equals(«»)) {

}

И добавляем в C #String.IsNullOrEmptyОбычная грамматика

if (string.IsNullOrEmpty(str)) {

}

Черт!

Каждый раз, когда вы пишете код, который путает пустые строки с пустыми строками, команда Guava плачет. -Google Guava

хорошо сказано. Но когда ваша система типов (например, Java или C #) допускает NULL везде, вы не можете надежно исключить возможность NULL и неизбежно где-то запутаетесь.

Возможность нулевого повсюду вызвала такую проблему, добавлена Java 8@NonNullМарк, попробуй ретроспективно устранить этот дефект в системе его типов.

3. NULL — это особый случай.

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

указатель

Например, рассмотрим следующий код C ++:

char c = ‘A’;

char *myChar = &c;

std::cout << *myChar << std::endl;

myChar Является char *, Что означает, что это указатель, то есть сохранить адрес памяти вcharв. Компилятор это проверит. Следовательно, следующий код недействителен:

char *myChar = 123; // compile error

std::cout << *myChar << std::endl;

Потому что123Нет гарантии, что это одинchar, Итак, компиляция не удалась. В любом случае, если поменять номер на0(0 является NULL в C ++), тогда его можно скомпилировать с помощью:

char *myChar = 0;

std::cout << *myChar << std::endl; // runtime error

с 123То же самое, NULL на самом деле неcharадрес. Но на этот раз компилятор все еще позволяет его компилировать, потому что0(NULL) — особый случай.

Нить

Есть еще один особый случай, который встречается в символьной строке, оканчивающейся на NULL в языке C. Это немного отличается от других примеров, потому что здесь нет указателей или ссылок. Однако идея о том, что это не ценность, а также играет роль ценности, все еще существует, здесь нетcharНо это играетcharСуществуют в виде.

Строка C представляет собой последовательность байтов и заканчивается байтом NUL (0).

Следовательно, каждый символ строки C может быть любым из 256 байтов, кроме 0 (то есть символа NUL). Это не только делает длину строки линейной операцией времени; что еще хуже, это означает, что строки C не могут использоваться в ASCII или расширенном ASCII. Вместо этого они могут использоваться только для ASCIIZ, который обычно не используется.

Исключение одного символа NUL вызвало бесчисленное количество ошибок: странное поведение API, уязвимости безопасности и переполнение буфера.

NULL — это наихудшая ошибка в строках C; точнее, строка, заканчивающаяся на NUL, являетсяСамый дорогойОдин байтошибка。

4. NULL делает API плохим

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

Хранилище ключей и значений

Предположим, мы создаем класс Ruby, который будет действовать как хранилище значений ключей. Это может быть кеш, интерфейс для базы данных ключ-значение и т. Д. Создадим простой и универсальный API:

class Store

# associate key with value

def set(key, value)

...

end

# get value associated with key, or return nil if there is no such key

def get(key)

...

end

Мы можем представить подобные классы на многих языках (Python, JavaScript, Java, C # и т. Д.).

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

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

store = Store.new()

store.set(‘Bob’, ‘801-555-5555’)

store.get(‘Bob’) # returns ‘801-555-5555’, which is Bob’s number

store.get(‘Alice’) # returns nil, since it does not have Alice

Однако у некоторых людей нет номера телефона (т.е. их номер телефона равен нулю). Мы по-прежнему будем кэшировать эту информацию, поэтому нам не нужно ее пополнять позже.

store = Store.new()

store.set(‘Ted’, nil) # Ted has no phone number

store.get(‘Ted’) # returns nil, since Ted does not have a phone number

Но теперь это означает, что наши результаты неоднозначны! Это может означать:

Этого человека нет в кеше (Алиса)
Этот человек существует в кеше, но у него нет номера телефона (Том)

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

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

Используйте одинcontains()Способ ремонтаStoreКласс может быть полезным. Но это вводит повторные поиски, что приводит к снижению производительности и условиям гонки.

Двойные неприятности

У JavaScript такая же проблема, но она возникает вКаждый объект。

Если атрибуты объекта не существуют, JS вернет значение, указывающее, что у объекта отсутствуют атрибуты. Разработчики JavaScript выбрали это значение равным нулю.

Они беспокоятся о том, когда свойство существует и для него установлено значение null. «Талант» в том, что JavaScript добавляет undefined, чтобы отличать свойства с нулевыми значениями от несуществующих свойств.

Но что, если свойство существует и его значение не определено? Странно то, что JavaScript остановился на этом и не предоставил «super undefined».

JavaScript предлагает не только одну, но и две формы NULL.

5. NULL ухудшает неправильные языковые решения

Java незаметно преобразует ссылки в основные типы. Добавление null делает ситуацию еще более странной.

Например, следующий код не компилируется:

int x = null; // compile error

Этот код компилируется и передается:

Integer i = null;

int x = i; // runtime error

Хотя он сообщит, когда код запускаетсяNullPointerException ошибка.

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

6. NULL сложно отлаживать.

Чтобы объяснить, насколько проблематичным является NULL, хорошим примером является C ++. Вызов функции-члена для указания на NULL-указатель не обязательно приводит к сбою программы. Хуже того: этомайПриведет к сбою программы.

#include <iostream>

struct Foo {

int x;

void bar() {

std::cout << «La la la» << std::endl;

}

void baz() {

std::cout << x << std::endl;

}

};

int main() {

Foo *foo = NULL;

foo->bar(); // okay

foo->baz(); // crash

}

Когда я использую gcc для компиляции приведенного выше кода, первый вызов выполняется успешно, а второй — нет.

Почему?foo->bar()Это известно во время компиляции, поэтому компилятор избегает поиска в виртуальной таблице во время выполнения и преобразует его в статический вызов, аналогичныйFoo_bar(foo), Возьмите это как первый параметр. Потому чтоbarНет косвенной ссылки на указатель NULL, поэтому он работает успешно. НоbazИмеется ссылка на указатель NULL, который вызывает segfault.

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

...

virtual void bar() {

...

В качестве виртуальной функцииfoo->bar()ЯвляетсяfooВыполните поиск в виртуальной таблице для типа среды выполнения, чтобы предотвратитьbar()Был переписан. Потому чтоfooИмеет значение NULL, текущая программа будетfoo->bar()Это предложение рухнуло, потому что мы превратили функцию в виртуальную.

int main() {

Foo *foo = NULL;

foo->bar(); // crash

foo->baz();

}

NULL сделалmainДля программистов функций отладка этого кода становится очень сложной и неинтуитивной.

Действительно, ссылка на NULL не определена в стандарте C ++, поэтому технически мы не должнылюбая ситуацияУдивлен. Кроме того, это непатологический, распространенный, очень простой и реальный пример.Этот пример является одним из многих примеров, когда NULL на практике непостоянен.

7. NULL нельзя комбинировать

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

Фактически, компоновка — действительно основная проблема, стоящая за многими из этих проблем. Например,StoreНет возможности компоновки между API, возвращающим nil несуществующему значению, и сохранением nil для несуществующего телефонного номера.

Для C #NullableЧтобы разобраться с некоторыми проблемами, связанными с NULL. Вы можете включить в тип необязательность (пустоту).

int a = 1; // integer

int? b = 2; // optional integer that exists

int? c = null; // optional integer that does not exist

Но это вызвало серьезный недостаток, то естьNullableНе применимо ни к какомуT. Применяется только к непустымT. Например, это не сделаетStoreПроблема исправлена любым способом.

Прежде всего stringМожет быть пустым; вы не можете создать непустойstring
Даже еслиstringНе пусто, поэтому создайтеstring? Может быть, но все равно нельзя исключить неоднозначность нынешней ситуации. Нет string？？

решение

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

не так! У вас может быть полный язык программирования без NULL. Проблема с NULL — это нечисловое значение, дозорный, особый случай, который концентрируется на всем остальном.

Вместо этого нам нужно, чтобы сущность содержала некоторую информацию о (1) содержит ли она значение и (2) содержащееся значение, если есть содержащееся значение. И эта сущность должна уметь «содержать» любой тип. Это идея Haskell’s Maybe, Java’s Optional, Swift’s Optional и т. Д.

Например, в ScalaSome[T]Сохранить одинTЗначение типа.NoneНет никакой ценности. Оба этиOption[T]Подтипы этих двух подтипов могут иметь значение или не иметь значения.

Читатели, не знакомые с Maybes / Options, могут подумать, что мы заменили одну форму (NULL) другой формой (None). Но есть одно отличие — обнаружить его непросто, но оно очень важно.

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

В динамически типизированном языке вы не можете спутать использование Maybes / Options с содержащимися значениями.

Вернемся к предыдущемуStore, Но на этот раз можно использовать рубин. Если есть значение, тоStoreКласс возвращается со значениемSome, В противном случае вернутьNone. Для телефонных номеровSomeЭто номер телефона,NoneУказывает на отсутствие номера телефона. Так что естьДва уровня присутствия / отсутствия:Внешний MaybeУказывает, что он существует вStoreВ; внутреннийMaybeУказывает номер телефона, соответствующий этому имени. Мы успешно объединили несколькоMaybe, Это то, что мы не можем сделать с nil.

cache = Store.new()

cache.set(‘Bob’, Some(‘801-555-5555’))

cache.set(‘Tom’, None())

bob_phone = cache.get(‘Bob’)

bob_phone.is_some # true, Bob is in cache

bob_phone.get.is_some # true, Bob has a phone number

bob_phone.get.get # ‘801-555-5555’

alice_phone = cache.get(‘Alice’)

alice_phone.is_some # false, Alice is not in cache

tom_phone = cache.get(‘Tom’)

tom_phone.is_some # true, Tom is in cache

tom_phone.get.is_some #false, Tom does not have a phone number

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

Используйте Maybes / Опции

Давайте продолжим обсуждение кода без NULL. Предположим, в Java 8+ у нас есть целое число, оно может существовать, а может и не существовать, и если оно существует, мы его распечатываем.

Optional<Integer> option = ...

if (option.isPresent()) {

doubled = System.out.println(option.get());

}

Замечательно. Но большая частьMaybe/OptionalРеализация, включая Java, поддерживает более практичный метод:

option.ifPresent(x -> System.out.println(x));

// or option.ifPresent(System.out::println)

Этот практический метод не только более краткий, но и более безопасный. Необходимо помнить, что если это значение не существует, тоoption.get()Произойдет ошибка. В предыдущем примереget()Получите одинifЗащита. В этом примереifPresent()Это полностью устраняет наши опасенияget()Необходимость. Это делает код явно свободным от ошибок, а не без ошибок.

Параметры можно рассматривать как набор с максимальным значением 1. Например, если есть значение, то мы можем умножить его на 2, в противном случае оставить его пустым.

При желании мы можем выполнить операцию, которая возвращает необязательное значение и стремится «сгладить» результат.

option.flatMap(x -> methodReturningOptional(x))

Если такового не существует, мы можем указать значение по умолчанию:

В целом,Maybe/OptionРеальная стоимость

Избавьтесь от небезопасных предположений о существовании и несуществовании ценностей.
Управляйте дополнительными данными проще и безопаснее
Явно заявляйте о любых предположениях о небезопасном существовании (например,.get()Метод)

Не быть NULL!

NULL — ужасный недостаток дизайна, постоянная и неизмеримая боль. Лишь немногим языкам удается избежать его ужаса.

Если вы все же выберете язык с NULL, то, по крайней мере, сознательно избегайте этой неприятности в своем собственном коде и используйте эквивалентMaybe/Option。

NULL в распространенных языках:

«Балл» определяется на основании следующих критериев:

редактировать

счет

Не относитесь слишком серьезно к «оценкам» в приведенной выше таблице. Настоящая проблема состоит в том, чтобы суммировать статус NULL на разных языках и представить альтернативы NULL, а не ранжировать часто используемые языки.

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

Пример: Haskell’sForeign.Ptr.nullPtrОн используется в FFI (интерфейсе внешних функций) для маршалинга значений в Haskell и обратно.
Пример: SwiftUnsafePointerДолжен быть сunsafeUnwrapИли же!использовать вместе.
Контрпример: Scala, несмотря на то, что обычно избегает null, по-прежнему обрабатывает null, как Java, для улучшения взаимодействия.val x: String = null

Когда NULL ОК?

Стоит отметить, что при сокращении циклов ЦП специальное значение того же размера, например 0 или NULL, может быть очень полезным, жертвуя качеством кода на производительность. Когда это действительно важно, это удобно для низкоуровневых языков, таких как C, но на самом деле стоит оставить все как есть.

Настоящая проблема

Более распространенная проблема с NULL — это контрольные значения: эти значения такие же, как и другие значения, но имеют совершенно другое значение. Из indexOfХорошим примером является возврат индекса целого числа или целого числа -1. Другой пример — строки, оканчивающиеся на NULL. В этой статье основное внимание уделяется NULL, что придает его универсальность и реальное влияние, но так же, как Саурон — всего лишь слуга Моргота, NULL — это просто форма базовой проблемы дозорного устройства.

Борьба с null

Здесь будет описано и рассказано про null с точки зрения разработчика на Java.

Борьба с null
- Да будет null
- Ближе к Java
- Техника безопасности
  - Не доверяй и проверяй
  - Проверяй
    - Аккуратность в проверках
  - Примитивы не так уж и примитивны
  - Аккуратнее со строками
  - Не плоди null
  - Отсутствие значения не всегда null
  - Optional
  - Доверяйте, но с аннотациями
- Заключение
- Полезные ссылки
- Отдельная благодарность

Да будет null

Для начала надо понять, как к null пришло человечество.

Во время написания кода в объектно-ориентированной парадигме вы представляете свою программу в виде совокупности и взаимодействия объектов, каждый из которых является экземпляром определённого класса.

И всё бы ничего, но что делать, если вам необходимо обозначить отсутствие объекта?
Например, отсутствие пользователя, какого-то ресурса и т.д.

Представьте, что вы написали класс, описывающий пользователя, одним из полей класса является адрес электронной почты — email.
Но не у всех пользователей есть email: кто-то вообще его не использует, кто-то не хочет указывать его или собирается это сделать позже.

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

Вам необходимо обозначить отсутствие объекта, и вот тут-то на сцену и выходит null.

Казалось бы, всё и на этом тему можно закрывать, ведь все довольны и счастливы! Не совсем.

Если вы попытаетесь вызвать любой метод на null, то неизбежно получите java.lang.NullPointerException. А если исключение не будет обработано, то это неизбежно послужит тому, что ваше приложение аварийно завершится.

В этом и состоит основная проблема использования null: это потенциальный источник java.lang.NullPointerException.

Недаром null называют ошибкой стоимостью в миллиард долларов.

Что такое null в Java?

«There is also a special null type, the type of the expression null, which has no name. Because the null type has no name,
it is impossible to declare a variable of the null type or to cast to the null type. The null reference is the only
possible value of an expression of null type. The null reference can always be cast to any reference type. In practice, the
programmer can ignore the null type and just pretend that null is merely a special literal that can be of any reference type.»
JLS 4.1

Из чего следует, что null в Java — это особое значение, оно не ассоциируется ни с каким типом (оператор instanceOf возвращает false, если в качестве параметра указать любую ссылочную переменную со значением null или null сам по себе) и может быть присвоено любой ссылочной переменной, а также возвращено из метода.

Это значит, что:

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

Чувствуете масштаб проблемы? Добавьте сюда ещё и тот факт, что null является значением по умолчанию для ссылочных типов, чтобы получить полное представление о ситуации с null-ами!

NPE

Однако, будет неверным считать, что null — это всегда зло, что он неуместен только из-за того, что его неаккуратное использование может привести к ошибкам. И ножом можно нанести повреждения, но это не делает нож плохим инструментом.

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

Но, как и в ситуации с ножом, у null тоже есть правила безопасности и о них мы и поговорим.

Техника безопасности

Рассмотрим следущий код:

public String greeting() {
    if (/* no greeting */) {
        return null;
    }

    return "Hello World!"
}

Подобный способ довольно распространен, вы пишите метод, а когда нет возвращаемого значения — отдаете null.
А теперь представьте как вы будете пользоваться (и как обрекаете на это других) этим методом?

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

String message = greeting();
int len = message.length();

Ведь у вас нет гарантии о том, что будет возвращено: значение или null. Вы теряете доверие к этому коду.
Это очень опасная и губительная практика: возвращение null из методов.

Но надо понимать, что нет ничего плохого в null как в значении, но null как reference — однозначное и чистое зло.

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

Для примера рассмотрим старого доброго Person-а, который скоро уже в суд подаст на нас за преследования:

public class Person {
    private int age;
    private String userName;
    private String email;

    public Person(final int age, final String userName) {
        this.age = age;
        this.userName = userName;
    }

    // getters and setters
}

Как уже было сказано не раз, null — это значение по умолчанию для ссылочных типов.
Соответственно, по умолчанию у объектов Person в поле email будет null.

В целом, подобный код часто встречается и это не плохо: у нас есть обязательные значения(name и age) и необязательные, которые могут отсутствовать — электронный адрес.

Не доверяй и проверяй

Самая явная и очевидная проверка на null в Java выглядит следующим образом:

if(person.getEmail() != null) {
    // do some work with email
}

В Java 7+ появился вспомогательный класс java.util.Objects, который содержит вспомогательные методы проверки на null:

     /**
     * Returns {@code true} if the provided reference is {@code null} otherwise
     * returns {@code false}.
     *
     * @apiNote This method exists to be used as a
     * {@link java.util.function.Predicate}, {@code filter(Objects::isNull)}
     *
     * @param obj a reference to be checked against {@code null}
     * @return {@code true} if the provided reference is {@code null} otherwise
     * {@code false}
     *
     * @see java.util.function.Predicate
     * @since 1.8
     */
    public static boolean isNull(Object obj) {
        return obj == null;
    }

    /**
     * Returns {@code true} if the provided reference is non-{@code null}
     * otherwise returns {@code false}.
     *
     * @apiNote This method exists to be used as a
     * {@link java.util.function.Predicate}, {@code filter(Objects::nonNull)}
     *
     * @param obj a reference to be checked against {@code null}
     * @return {@code true} if the provided reference is non-{@code null}
     * otherwise {@code false}
     *
     * @see java.util.function.Predicate
     * @since 1.8
     */
    public static boolean nonNull(Object obj) {
        return obj != null;
    }

Однако, эти методы были добавлены в основном для Java Stream API, для удобного использования в filter.
Да и на мой взгляд, обычная проверка более читабельна и явная, сравните:

if(Objects.nonNull(person.getEmail())) {
    // do some work with email
}

// vs

if(person.getEmail() != null) {
    // do some work with email
}

Проверяй

Несмотря на все наши усилия и договорённости, null может также просочиться в объект ещё на этапе его создания.

final Person person = new Person(20, null);

Объект будет создан, несмотря на то, что не ожидается, что поле userName может быть null.
Логичным решением будет потребовать уже на этапе создания объекта невозможность присвоения null значения такому полю.

Т.е. перед инициализацией проверить допустимость значений, которые получены конструктором.

К счастью, для этого в уже знакомом java.util.Objects есть необходимые методы:

public static <T> T requireNonNull(T obj) {
    if (obj == null)
        throw new NullPointerException();
    return obj;
}

public static <T> T requireNonNull(T obj, String message) {
    if (obj == null)
        throw new NullPointerException(message);
    return obj;
}

Благодаря чему, наш Person приобретает дополнительные проверки и вы всегда быстро поймёте какое поле было проинициализировано неправильно:

public Person(final int age, final String userName) {
    this.age = age;
    this.userName = Objects.requireNonNull(userName, "userName can't be null");
}

Вопрос:

Постойте, ведь в Java давно есть assert, а что насчёт них?

Ответ:

Да, есть и их также можно использовать для валидации значений:

public Person(final int age, final String userName) {
    assert userName != null;

    this.age = age;
    this.userName = userName;
}

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

По умолчанию они отключены.
Такая проверка, в случае проблемы, кидает java.lang.AssertionError, что осложняет обработку исключений в проекте и дальнейшую отладку.

Более подробно о проверках.

Аккуратность в проверках

Помните, что вызов метода на null неизбежно породит java.lang.NullPointerException:

public void checkTag(final String tag) {
    tag.equals("UNKNOWN"); // может быть NPE, если tag = null
    "UNKNOWN".equals(tag); // безопасно
}

Поэтому, при работе с константами, enum-ами и т.д. вызывайте методы на константах, как наиболее безопасном месте.

Примитивы не так уж и примитивны

Будьте аккуратны с boxing/unboxing.

Как вы думаете, что будет при выполнении следующего кода:

public void printInt(Integer num) {
    System.out.println((int) num);
}

printInt(null);

А будет уже знакомый и горячо любимый java.lang.NullPointerException, возникший как раз в unboxing-е.

Поэтому будьте аккуратнее с boxing/unboxing и null-ами, по возможности пользуйтесь примитивами.

Аккуратнее со строками

Помните, что при конкатенации строк, если там затесалось null значение, не будет java.lang.NullPointerException, но и игнорирования null не будет:

String s1 = "hello";
String s2 = null;
String s3 = s1 + s2;
String s4 = new StringBuilder(s1).append(s2).toString();

System.out.println(s3);
System.out.println(s4);

В итоге в обоих случаях будет: hello null!

Человечество, кому повезло не быть разработчиками, ещё не готово к таким наскальным надписям, поэтому, дабы не удивляться null-ам в UI и логах, используйте java.util.Objects, Google Guava или Apache Commons библиотеки.

Например, как это сделано в java.util.Objects:

    /**
     * Returns the result of calling {@code toString} on the first
     * argument if the first argument is not {@code null} and returns
     * the second argument otherwise.
     *
     * @param o an object
     * @param nullDefault string to return if the first argument is
     *        {@code null}
     * @return the result of calling {@code toString} on the first
     * argument if it is not {@code null} and the second argument
     * otherwise.
     * @see Objects#toString(Object)
     */
    public static String toString(Object o, String nullDefault) {
        return (o != null) ? o.toString() : nullDefault;
    }

В таком случае:

String s3 = Objects.toString(s1, "") + Objects.toString(s2, "");

Но я рекомендую использовать Apache Commons и класс StringUtils. Удобная и безопасная работа со строками с учётом null-ов.

Не плоди null

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

Например, обновление статуса с дополнительной информацией (по возможности):

public void updateStatus(final String status, final String details) {
    // some code
}

При этом, details вполне может отсутствовать и зачастую использование сводится к:

updateStatus("NEW", "Creating new order status");
updateStatus("NEW", null);  // при отсутствии details

В таком случае, лучше перегрузить метод и сделать:

public void updateStatus(final String status, final String details) {
    // some code
}

public void updateStatus(final String status) {
    // some code
}

Старайтесь минимизировать явную передачу null в методы.

Во-первых, null в методе делает его менее читабельным, особенно, если null значений несколько, например:

updateStatus("NEW", null, null, 200)

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

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

Отсутствие значения не всегда null

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

Разберём пример: вы написали телефонную книгу, где есть возможность получить список номеров по имени абонента:

public List<Person> findByName(final String name) {
    if(book.contains(name)) {
        return persons;
    }

    return null;
}

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

Казалось бы, всё правильно, но нет!

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

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

public List<Person> findByNameAndTags(final String name, final Set<Tag> tags) {
    // some code
}

Если tags необязательное значение для поиска, то при отсутствии значения передавайте пустое множество:

findByNameAndTags("Kuchuk", ImmutableSet.of())

Либо сделайте два метода: с tags в сигнатуре и без.

// когда tags обязательно
public List<Person> findByNameAndTags(final String name, final Set<Tag> tags) {
    // some code
}

// когда tags необязательно
public List<Person> findByNameAndTags(final String name) {
    // some code
}

Точно тот же совет, когда коллекция — это поле класса.

Например, вам необходимо множество кодов ошибок в валидаторе значений:

public class Validator {
    private Set<Integer> codes = new HashSet<>();

    // some code
}

Если нет множества(не инициализировали, отсутствует) — сделайте его пустым множеством. Но не делайте его null!

Как вариант можно возвращать ещё итератор.

Отстутствие значения при работе с коллекциями — это пустая коллекция.
При работе с коллекциями и отношением данных one-to-many отсутствие значения — это и есть пустая коллекция.

Optional

Начиная с Java 8+ для борьбы с null был добавлен класс java.util.Optional.
Класс был добавлен для того, чтобы дать возможность разработчикам явно показывать, что значения может не быть.

Если объяснять на пальцах, то java.util.Optional — это просто контейнер, в который вы оборачиваете значение. При отсутствии значения у вас пустой контейнер, при существовании значения — у вас контейнер со значением.

/**
 * A container object which may or may not contain a non-null value.
 * If a value is present, {@code isPresent()} will return {@code true} and
 * {@code get()} will return the value.
 *
 * <p>Additional methods that depend on the presence or absence of a contained
 * value are provided, such as {@link #orElse(java.lang.Object) orElse()}
 * (return a default value if value not present) and
 * {@link #ifPresent(java.util.function.Consumer) ifPresent()} (execute a block
 * of code if the value is present).
 *
 * <p>This is a <a href="../lang/doc-files/ValueBased.html">value-based</a>
 * class; use of identity-sensitive operations (including reference equality
 * ({@code ==}), identity hash code, or synchronization) on instances of
 * {@code Optional} may have unpredictable results and should be avoided.
 *
 * @since 1.8
 */
public final class Optional<T> { 
    // ...
}

Для работы Optional с примитивами существует: java.util.OptionalInt, java.util.OptionalLong и java.util.OptionalDouble.

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

public Person findByNameAndSurname(final String name, final String surname) {
    // some code
}

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

Что делать в таком случае?

Варианта, на самом деле, три:

Кинуть исключение
Вернуть null
Вернуть Optional

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

public Optional<Person> findByNameAndSurname(final String name, final String surname) {
    // some code
}

В таком случае, использование может быть в виде:

Optional<Person> person = findByNameAndSurname("Aleksandr", "Kuchuk");

if(person.isPresent()) {
    // нашли пользователя
} else {
    // не нашли
}

Помимо примитивной проверки в if-е Optional можно(и нужно) использовать в Java Stream API:

// ifPresent - совершение действия при существовании значения
final Optional.ofNullable(person.getEmail).ifPresent(email -> System.out.println(email));

// map и orElse - при существовании применить функцию к значению, если нет - вернуть unknown 
final String email = Optional.ofNullable(p.getEmail()).map(String::toLowerCase).orElse("unknown");

Однако, Optional, на мой взгляд, имеет смысл использовать только в качестве возвращаемых значений.
Определенно не стоит его использовать в качестве параметров метода, поскольку при использовании Optional в качестве параметров метода теряется читабельность, код становится более громоздким, проверят на null придеться всё равно и поэтому лучше предоставить действительное значение или сделать перегрузку метода в случаях, когда параметр необязателен.

Также и с полями класса. Нет смысла делать поля класса Optional, так как это будет не Java Bean, также Optional является не сериализуемым классом и т.д.

Есть три способа создать Optional:

    /**
     * Returns an empty {@code Optional} instance.  No value is present for this
     * Optional.
     *
     * @apiNote Though it may be tempting to do so, avoid testing if an object
     * is empty by comparing with {@code ==} against instances returned by
     * {@code Option.empty()}. There is no guarantee that it is a singleton.
     * Instead, use {@link #isPresent()}.
     *
     * @param <T> Type of the non-existent value
     * @return an empty {@code Optional}
     */
    public static<T> Optional<T> empty() {
        @SuppressWarnings("unchecked")
        Optional<T> t = (Optional<T>) EMPTY;
        return t;
    }

    /**
     * Returns an {@code Optional} with the specified present non-null value.
     *
     * @param <T> the class of the value
     * @param value the value to be present, which must be non-null
     * @return an {@code Optional} with the value present
     * @throws NullPointerException if value is null
     */
    public static <T> Optional<T> of(T value) {
        return new Optional<>(value);
    }

    /**
     * Returns an {@code Optional} describing the specified value, if non-null,
     * otherwise returns an empty {@code Optional}.
     *
     * @param <T> the class of the value
     * @param value the possibly-null value to describe
     * @return an {@code Optional} with a present value if the specified value
     * is non-null, otherwise an empty {@code Optional}
     */
    public static <T> Optional<T> ofNullable(T value) {
        return value == null ? empty() : of(value);
    }

Используйте:

Optional.empty() в случае, если вы уверены, что необходимо вернуть пустой контейнер.
Optional.of(value) в случае, если вы уверены, что значение, value, которое вы собираетесь положить в контейнер совершенно точно не null.
В противном случае используйте Optional.ofNullable(value).

Никогда не смешивайте null и Optional:

Optional<Object> optional = null; // Плохо!
Optional<Object> optional = Optional.of(null); // exception

Это путь в ад и к ненависти.

Подробно о Optional.

Доверяйте, но с аннотациями

Но как быть тому, кто будет использовать ваш код, понять, какие поля вы какие поля могут по нашей задумке быть null, а какие — нет, и это явная ошибка?

Ведь это нам, как разработчикам этого кода, прозрачно и понятно, что email-а может не быть и это нормальное поведение кода.
Другим разработчикам, да и нам самим через неделю, это абсолютно не ясно — и из этого возникает мысль, что было бы удобно как-то разметить наш класс, показать, где ожидаем null и это заложено, а где не ожидаем и это ошибка на миллион долларов.

Может ли поле быть с null или нет — это уже метаинформация о поле. А, значит, логично воспользоваться аннотациями.

К сожалению, в Java нет какого-то общего стандарта, и существует несколько видов аннотаций для этого, например:

javax.validation.constraints.NotNull
javax.annotation.Nonnull
org.jetbrains.annotations.NotNull
lombok.NonNull
org.eclipse.jdt.annotation.NonNull

В целом, я уверен, существуют еще несколько, но я выделил наиболее популярные (исключая Android специфичные) на данный момент.

Какую выбрать и как использовать?

На самом деле, вопрос сложный, но я в своих проектах пользуюсь тем, что предоставляет JSR-305, т.е javax.annotation.Nonnull и т.д.

Почему?
Дело в том, что я стараюсь избегать ссылок на IDE специфичные аннотации, поэтому jetbrains, lombok и eclipse отпадают.
Остается только javax.annotation и javax.validation.constraints.
Я сделал выбор в пользу первой как более простой, наглядной и распространённой.
Вообще, это довольно холиварный вопрос, но, если вы пишите на Java 8, то JSR-305 будет к месту.

Подробнее об этом тут и тут.

Благодаря плагину и аннотациям из JSR-305 получается разметить и сгенерировать код с билдерами и проверками на null:

import javax.annotation.Nonnull;
import javax.annotation.Nullable;
import javax.annotation.ParametersAreNonnullByDefault;
import java.util.Objects;

@ParametersAreNonnullByDefault
public class Person {
    @Nonnull
    private final String name;

    @Nullable
    private final String email;

    private final int age;


    private Person(Builder builder) {
        this.name = Objects.requireNonNull(builder.name, "name");
        this.age = Objects.requireNonNull(builder.age, "age");
        this.email = builder.email;
    }

    public static Builder builder() {
        return new Builder();
    }

    @Nonnull
    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }

    @Nullable
    public String getEmail() {
        return email;
    }

    public static class Builder {
        private String name;
        private Integer age;
        private String email;

        private Builder() {
        }

        public Builder setName(String name) {
            this.name = name;
            return this;
        }

        public Builder setAge(int age) {
            this.age = age;
            return this;
        }

        public Builder setEmail(@Nullable String email) {
            this.email = email;
            return this;
        }

        public Builder of(Person person) {
            this.name = person.name;
            this.age = person.age;
            this.email = person.email;
            return this;
        }

        public Person build() {
            return new Person(this);
        }
    }
}

Аннотация @ParametersAreNonnullByDefault на классе говорит о том, что все параметры в методах по умолчанию @Nonnull.

Но не возвращаемые значения!
Возвращаемые значения надо размечать вручную самому и явно.

Это довольно удобно и практично.

Однако, надо понимать, что эти аннотации — не более, чем разметка, чтобы облегчить и структурировать себе и потомкам понимание логики.

Грубо говоря, это как разметка на дороге, вы понимаете, где может быть опасное место, а где в целом безопасный отрезок трассы, но это не защитит вас от грузовика по встречной полосе, если кто-то на нём вырулит:

public void printStatus(@Nonnull String status) {
    // some code
}

printStatus(null);  // тот самый грузовик по встречной полосе

Аннотации — не более, чем рекомендации и описание правил, которые в идеале должны соблюдать все участники проекта.
Но они могут и не соблюдать их!

Заключение

При разработке не бойтесь null, но старайтесь минимизировать его использование.
Нет ничего плохого в null как в значении, но null как reference — однозначное и чистое зло.

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

Помните, что отсутствие значения у коллекции — это чаще всего пустая коллекция или пустой итератор.

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

Старайтесь использовать pre-conditions с помощью Objects.requireNonNull — чем раньше вы поймёте где проблема и с чем, тем лучше.

Будьте аккуратнее со строками и boxing/unboxing!

Полезные ссылки

Null pointer в разных языках программирования
Спецификация Java про null
Про null
Когда использовать NonNull аннотации
Про проверки на null
Какие аннотации для null использовать
Про Optional
Java Optional — попытка избежать NullPoinerException
Ещё про Optional
Про Null.Часть 1
Про Null.Часть 2
Stop Abusing Nihil
Java. Проблема с null. Null safety.

Отдельная благодарность

Отдельную благодарность за ревью и помощь автор хочет выразить следующим людям из твиттера:

@norrittmobile
@thecoldwine
@mudasobwa
@dmi3vim
@ihavenoclue12

Источник

Что такое null в Java

Object obj1 = NULL; // Неверно
Object obj2 = null; // ОК

private static Object myObj;
public static void main(String args[]){
    System.out.println("Значение myObj : " + myObj);
}

// Значение myObjc: 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; // без ошибок.

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 при запуске

Integer iAmNull = null;
int i = iAmNull; // компиляция пройдет успешно

import java.util.HashMap;
import java.util.Map;

public class Test {

    public static void main(String args[]) throws InterruptedException {

        Map<Integer, Integer> numberAndCount = new HashMap<>();

        int[] numbers = {3, 5, 7, 9, 11, 13, 17, 19, 2, 3, 5, 33, 12, 5};

        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)

6. Оператор instanceof вернет false, будучи примененным к переменной со значением null или к литералу null:

Integer iAmNull = null;
if (iAmNull instanceof Integer) {
    System.out.println("iAmNull — экземпляр Integer");
} else {
    System.out.println("iAmNull не является экземпляром Integer");
}

Результат выполнения:

iAmNull не является экземпляром Integer

Это важное свойство оператора instanceof, которое делает его полезным при приведении типов.

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)

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

_{Перевод статьи «9 Things about Null in Java»}

Источник

[Обновление 2015-10-31] Дополнительная трансляция, измененная из StackOverflowПочтовыйПараграф:

Чашка! В нашей компании фамилия сотрудника Null.При использовании его фамилии в качестве термина запроса все приложения запросов сотрудников вылетали из строя! Что я должен делать?

«Я называю нулевую ссылку своей ошибкой на миллиард долларов. Она была изобретена в 1965 году, когда я разработал первую всеобъемлющую систему ссылочных типов на объектно-ориентированном языке (АЛГОЛ W). Моя цель — гарантировать, что использование всех ссылок абсолютно безопасно, компилятор проверит автоматически. Но я не смог устоять перед соблазном добавить нулевые ссылки только потому, что это очень легко реализовать. Это вызвало бесчисленное количество ошибок, уязвимостей и систем. Авария могла привести к убыткам в миллиарды долларов в следующий раз. 40 лет. В последние годы люди начали использовать различные программы анализа программ, такие как Microsoft PREfix и PREfast, чтобы проверять ссылки и предупреждать, если существует риск ненулевого значения. Новые языки программирования, такие как Spec #, имеют ввел объявление ненулевых ссылок. Это решение, которое я отверг в 1965 году »-« Нулевые ссылки: ошибка на миллиард долларов »Тони Хоар, лауреат премии Тьюринга

Что не так с NULL?

Проще говоря: NULL — это значение, которое не является значением. Вот и проблема.

NULL…

Тип Subversion
Это грязно
Это особый случай
Сделать API хуже
Сделать неправильные языковые решения хуже
Сложно отлаживать
Не сочетается

1. Тип подрывной деятельности NULL

toUppercase()Может быть произвольноStringВызов объекта. Пока неStringНулевой.
read()Может быть произвольноInputStreamВызов объекта. Пока неInputStreamНулевой.
toString()Может быть произвольноObjectВызов объекта. Пока неObjectНулевой.

2. NULL беспорядочный

Программисты на Java пишут о риске синдрома запястного канала

if (str == null || str.equals(«»)) {

}

И добавляем в C #String.IsNullOrEmptyОбычная грамматика

if (string.IsNullOrEmpty(str)) {

}

Черт!

Каждый раз, когда вы пишете код, который путает пустые строки с пустыми строками, команда Guava плачет. -Google Guava

3. NULL — это особый случай.

указатель

Например, рассмотрим следующий код C ++:

char c = ‘A’;

char *myChar = &c;

std::cout << *myChar << std::endl;

char *myChar = 123; // compile error

std::cout << *myChar << std::endl;

char *myChar = 0;

std::cout << *myChar << std::endl; // runtime error

Нить

Строка C представляет собой последовательность байтов и заканчивается байтом NUL (0).

4. NULL делает API плохим

Хранилище ключей и значений

class Store

# associate key with value

def set(key, value)

...

end

# get value associated with key, or return nil if there is no such key

def get(key)

...

end

Мы можем представить подобные классы на многих языках (Python, JavaScript, Java, C # и т. Д.).

store = Store.new()

store.set(‘Bob’, ‘801-555-5555’)

store.get(‘Bob’) # returns ‘801-555-5555’, which is Bob’s number

store.get(‘Alice’) # returns nil, since it does not have Alice

store = Store.new()

store.set(‘Ted’, nil) # Ted has no phone number

store.get(‘Ted’) # returns nil, since Ted does not have a phone number

Но теперь это означает, что наши результаты неоднозначны! Это может означать:

Этого человека нет в кеше (Алиса)
Этот человек существует в кеше, но у него нет номера телефона (Том)

Двойные неприятности

У JavaScript такая же проблема, но она возникает вКаждый объект。

JavaScript предлагает не только одну, но и две формы NULL.

5. NULL ухудшает неправильные языковые решения

Java незаметно преобразует ссылки в основные типы. Добавление null делает ситуацию еще более странной.

Например, следующий код не компилируется:

int x = null; // compile error

Этот код компилируется и передается:

Integer i = null;

int x = i; // runtime error

Хотя он сообщит, когда код запускаетсяNullPointerException ошибка.

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

6. NULL сложно отлаживать.

#include <iostream>

struct Foo {

int x;

void bar() {

std::cout << «La la la» << std::endl;

}

void baz() {

std::cout << x << std::endl;

}

};

int main() {

Foo *foo = NULL;

foo->bar(); // okay

foo->baz(); // crash

}

Когда я использую gcc для компиляции приведенного выше кода, первый вызов выполняется успешно, а второй — нет.

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

...

virtual void bar() {

...

int main() {

Foo *foo = NULL;

foo->bar(); // crash

foo->baz();

}

NULL сделалmainДля программистов функций отладка этого кода становится очень сложной и неинтуитивной.

7. NULL нельзя комбинировать

int a = 1; // integer

int? b = 2; // optional integer that exists

int? c = null; // optional integer that does not exist

Прежде всего stringМожет быть пустым; вы не можете создать непустойstring
Даже еслиstringНе пусто, поэтому создайтеstring? Может быть, но все равно нельзя исключить неоднозначность нынешней ситуации. Нет string？？

решение

В динамически типизированном языке вы не можете спутать использование Maybes / Options с содержащимися значениями.

cache = Store.new()

cache.set(‘Bob’, Some(‘801-555-5555’))

cache.set(‘Tom’, None())

bob_phone = cache.get(‘Bob’)

bob_phone.is_some # true, Bob is in cache

bob_phone.get.is_some # true, Bob has a phone number

bob_phone.get.get # ‘801-555-5555’

alice_phone = cache.get(‘Alice’)

alice_phone.is_some # false, Alice is not in cache

tom_phone = cache.get(‘Tom’)

tom_phone.is_some # true, Tom is in cache

tom_phone.get.is_some #false, Tom does not have a phone number

Используйте Maybes / Опции

Optional<Integer> option = ...

if (option.isPresent()) {

doubled = System.out.println(option.get());

}

Замечательно. Но большая частьMaybe/OptionalРеализация, включая Java, поддерживает более практичный метод:

option.ifPresent(x -> System.out.println(x));

// or option.ifPresent(System.out::println)

option.flatMap(x -> methodReturningOptional(x))

Если такового не существует, мы можем указать значение по умолчанию:

В целом,Maybe/OptionРеальная стоимость

Избавьтесь от небезопасных предположений о существовании и несуществовании ценностей.
Управляйте дополнительными данными проще и безопаснее
Явно заявляйте о любых предположениях о небезопасном существовании (например,.get()Метод)

Не быть NULL!

NULL в распространенных языках:

«Балл» определяется на основании следующих критериев:

редактировать

счет

Пример: Haskell’sForeign.Ptr.nullPtrОн используется в FFI (интерфейсе внешних функций) для маршалинга значений в Haskell и обратно.
Пример: SwiftUnsafePointerДолжен быть сunsafeUnwrapИли же!использовать вместе.
Контрпример: Scala, несмотря на то, что обычно избегает null, по-прежнему обрабатывает null, как Java, для улучшения взаимодействия.val x: String = null

Когда NULL ОК?

Настоящая проблема

Источник

Java

Чем опасен null?

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

Когда Null уместен, а когда нет

Возвращение null

Представим метод, извлекающий из базы данных информацию о госпитализации данного пациента:

public Admission getAdmission(Patient patient);

Применение шаблона нулевого объекта к структуре дерева

Передача нулевых параметров

Как же полностью избежать нулевых параметров?

Воспринимайте null правильно

Борьба с null

Здесь будет описано и рассказано про null с точки зрения разработчика на Java.

Борьба с null
- Да будет null
- Ближе к Java
- Техника безопасности
  - Не доверяй и проверяй
  - Проверяй
    - Аккуратность в проверках
  - Примитивы не так уж и примитивны
  - Аккуратнее со строками
  - Не плоди null
  - Отсутствие значения не всегда null
  - Optional
  - Доверяйте, но с аннотациями
- Заключение
- Полезные ссылки
- Отдельная благодарность

Да будет null

Для начала надо понять, как к null пришло человечество.

Вам необходимо обозначить отсутствие объекта, и вот тут-то на сцену и выходит null.

Казалось бы, всё и на этом тему можно закрывать, ведь все довольны и счастливы! Не совсем.

В этом и состоит основная проблема использования null: это потенциальный источник java.lang.NullPointerException.

Недаром null называют ошибкой стоимостью в миллиард долларов.

Ближе к Java

Что такое null в Java?

«There is also a special null type, the type of the expression null, which has no name. Because the null type has no name,
it is impossible to declare a variable of the null type or to cast to the null type. The null reference is the only
possible value of an expression of null type. The null reference can always be cast to any reference type. In practice, the
programmer can ignore the null type and just pretend that null is merely a special literal that can be of any reference type.»
JLS 4.1

Это значит, что:

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

NPE

Но, как и в ситуации с ножом, у null тоже есть правила безопасности и о них мы и поговорим.

Техника безопасности

Рассмотрим следущий код:

public String greeting() {
    if (/* no greeting */) {
        return null;
    }

    return "Hello World!"
}

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

String message = greeting();
int len = message.length();

Но надо понимать, что нет ничего плохого в null как в значении, но null как reference — однозначное и чистое зло.

Для примера рассмотрим старого доброго Person-а, который скоро уже в суд подаст на нас за преследования:

public class Person {
    private int age;
    private String userName;
    private String email;

    public Person(final int age, final String userName) {
        this.age = age;
        this.userName = userName;
    }

    // getters and setters
}

Не доверяй и проверяй

Самая явная и очевидная проверка на null в Java выглядит следующим образом:

if(person.getEmail() != null) {
    // do some work with email
}

В Java 7+ появился вспомогательный класс java.util.Objects, который содержит вспомогательные методы проверки на null:

     /**
     * Returns {@code true} if the provided reference is {@code null} otherwise
     * returns {@code false}.
     *
     * @apiNote This method exists to be used as a
     * {@link java.util.function.Predicate}, {@code filter(Objects::isNull)}
     *
     * @param obj a reference to be checked against {@code null}
     * @return {@code true} if the provided reference is {@code null} otherwise
     * {@code false}
     *
     * @see java.util.function.Predicate
     * @since 1.8
     */
    public static boolean isNull(Object obj) {
        return obj == null;
    }

    /**
     * Returns {@code true} if the provided reference is non-{@code null}
     * otherwise returns {@code false}.
     *
     * @apiNote This method exists to be used as a
     * {@link java.util.function.Predicate}, {@code filter(Objects::nonNull)}
     *
     * @param obj a reference to be checked against {@code null}
     * @return {@code true} if the provided reference is non-{@code null}
     * otherwise {@code false}
     *
     * @see java.util.function.Predicate
     * @since 1.8
     */
    public static boolean nonNull(Object obj) {
        return obj != null;
    }

if(Objects.nonNull(person.getEmail())) {
    // do some work with email
}

// vs

if(person.getEmail() != null) {
    // do some work with email
}

Проверяй

Несмотря на все наши усилия и договорённости, null может также просочиться в объект ещё на этапе его создания.

final Person person = new Person(20, null);

Т.е. перед инициализацией проверить допустимость значений, которые получены конструктором.

К счастью, для этого в уже знакомом java.util.Objects есть необходимые методы:

public static <T> T requireNonNull(T obj) {
    if (obj == null)
        throw new NullPointerException();
    return obj;
}

public static <T> T requireNonNull(T obj, String message) {
    if (obj == null)
        throw new NullPointerException(message);
    return obj;
}

public Person(final int age, final String userName) {
    this.age = age;
    this.userName = Objects.requireNonNull(userName, "userName can't be null");
}

Вопрос:

Постойте, ведь в Java давно есть assert, а что насчёт них?

Ответ:

Да, есть и их также можно использовать для валидации значений:

public Person(final int age, final String userName) {
    assert userName != null;

    this.age = age;
    this.userName = userName;
}

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

По умолчанию они отключены.
Такая проверка, в случае проблемы, кидает java.lang.AssertionError, что осложняет обработку исключений в проекте и дальнейшую отладку.

Более подробно о проверках.

Аккуратность в проверках

Помните, что вызов метода на null неизбежно породит java.lang.NullPointerException:

public void checkTag(final String tag) {
    tag.equals("UNKNOWN"); // может быть NPE, если tag = null
    "UNKNOWN".equals(tag); // безопасно
}

Примитивы не так уж и примитивны

Будьте аккуратны с boxing/unboxing.

Как вы думаете, что будет при выполнении следующего кода:

public void printInt(Integer num) {
    System.out.println((int) num);
}

printInt(null);

А будет уже знакомый и горячо любимый java.lang.NullPointerException, возникший как раз в unboxing-е.

Поэтому будьте аккуратнее с boxing/unboxing и null-ами, по возможности пользуйтесь примитивами.

Аккуратнее со строками

String s1 = "hello";
String s2 = null;
String s3 = s1 + s2;
String s4 = new StringBuilder(s1).append(s2).toString();

System.out.println(s3);
System.out.println(s4);

В итоге в обоих случаях будет: hello null!

Например, как это сделано в java.util.Objects:

    /**
     * Returns the result of calling {@code toString} on the first
     * argument if the first argument is not {@code null} and returns
     * the second argument otherwise.
     *
     * @param o an object
     * @param nullDefault string to return if the first argument is
     *        {@code null}
     * @return the result of calling {@code toString} on the first
     * argument if it is not {@code null} and the second argument
     * otherwise.
     * @see Objects#toString(Object)
     */
    public static String toString(Object o, String nullDefault) {
        return (o != null) ? o.toString() : nullDefault;
    }

В таком случае:

String s3 = Objects.toString(s1, "") + Objects.toString(s2, "");

Но я рекомендую использовать Apache Commons и класс StringUtils. Удобная и безопасная работа со строками с учётом null-ов.

Не плоди null

Например, обновление статуса с дополнительной информацией (по возможности):

public void updateStatus(final String status, final String details) {
    // some code
}

При этом, details вполне может отсутствовать и зачастую использование сводится к:

updateStatus("NEW", "Creating new order status");
updateStatus("NEW", null);  // при отсутствии details

В таком случае, лучше перегрузить метод и сделать:

public void updateStatus(final String status, final String details) {
    // some code
}

public void updateStatus(final String status) {
    // some code
}

Старайтесь минимизировать явную передачу null в методы.

Во-первых, null в методе делает его менее читабельным, особенно, если null значений несколько, например:

updateStatus("NEW", null, null, 200)

Отсутствие значения не всегда null

public List<Person> findByName(final String name) {
    if(book.contains(name)) {
        return persons;
    }

    return null;
}

Казалось бы, всё правильно, но нет!

public List<Person> findByNameAndTags(final String name, final Set<Tag> tags) {
    // some code
}

Если tags необязательное значение для поиска, то при отсутствии значения передавайте пустое множество:

findByNameAndTags("Kuchuk", ImmutableSet.of())

Либо сделайте два метода: с tags в сигнатуре и без.

// когда tags обязательно
public List<Person> findByNameAndTags(final String name, final Set<Tag> tags) {
    // some code
}

// когда tags необязательно
public List<Person> findByNameAndTags(final String name) {
    // some code
}

Точно тот же совет, когда коллекция — это поле класса.

Например, вам необходимо множество кодов ошибок в валидаторе значений:

public class Validator {
    private Set<Integer> codes = new HashSet<>();

    // some code
}

Если нет множества(не инициализировали, отсутствует) — сделайте его пустым множеством. Но не делайте его null!

Как вариант можно возвращать ещё итератор.

Optional

/**
 * A container object which may or may not contain a non-null value.
 * If a value is present, {@code isPresent()} will return {@code true} and
 * {@code get()} will return the value.
 *
 * <p>Additional methods that depend on the presence or absence of a contained
 * value are provided, such as {@link #orElse(java.lang.Object) orElse()}
 * (return a default value if value not present) and
 * {@link #ifPresent(java.util.function.Consumer) ifPresent()} (execute a block
 * of code if the value is present).
 *
 * <p>This is a <a href="../lang/doc-files/ValueBased.html">value-based</a>
 * class; use of identity-sensitive operations (including reference equality
 * ({@code ==}), identity hash code, or synchronization) on instances of
 * {@code Optional} may have unpredictable results and should be avoided.
 *
 * @since 1.8
 */
public final class Optional<T> { 
    // ...
}

Для работы Optional с примитивами существует: java.util.OptionalInt, java.util.OptionalLong и java.util.OptionalDouble.

public Person findByNameAndSurname(final String name, final String surname) {
    // some code
}

Что делать в таком случае?

Варианта, на самом деле, три:

Кинуть исключение
Вернуть null
Вернуть Optional

public Optional<Person> findByNameAndSurname(final String name, final String surname) {
    // some code
}

В таком случае, использование может быть в виде:

Optional<Person> person = findByNameAndSurname("Aleksandr", "Kuchuk");

if(person.isPresent()) {
    // нашли пользователя
} else {
    // не нашли
}

Помимо примитивной проверки в if-е Optional можно(и нужно) использовать в Java Stream API:

// ifPresent - совершение действия при существовании значения
final Optional.ofNullable(person.getEmail).ifPresent(email -> System.out.println(email));

// map и orElse - при существовании применить функцию к значению, если нет - вернуть unknown 
final String email = Optional.ofNullable(p.getEmail()).map(String::toLowerCase).orElse("unknown");

Есть три способа создать Optional:

    /**
     * Returns an empty {@code Optional} instance.  No value is present for this
     * Optional.
     *
     * @apiNote Though it may be tempting to do so, avoid testing if an object
     * is empty by comparing with {@code ==} against instances returned by
     * {@code Option.empty()}. There is no guarantee that it is a singleton.
     * Instead, use {@link #isPresent()}.
     *
     * @param <T> Type of the non-existent value
     * @return an empty {@code Optional}
     */
    public static<T> Optional<T> empty() {
        @SuppressWarnings("unchecked")
        Optional<T> t = (Optional<T>) EMPTY;
        return t;
    }

    /**
     * Returns an {@code Optional} with the specified present non-null value.
     *
     * @param <T> the class of the value
     * @param value the value to be present, which must be non-null
     * @return an {@code Optional} with the value present
     * @throws NullPointerException if value is null
     */
    public static <T> Optional<T> of(T value) {
        return new Optional<>(value);
    }

    /**
     * Returns an {@code Optional} describing the specified value, if non-null,
     * otherwise returns an empty {@code Optional}.
     *
     * @param <T> the class of the value
     * @param value the possibly-null value to describe
     * @return an {@code Optional} with a present value if the specified value
     * is non-null, otherwise an empty {@code Optional}
     */
    public static <T> Optional<T> ofNullable(T value) {
        return value == null ? empty() : of(value);
    }

Используйте:

Optional.empty() в случае, если вы уверены, что необходимо вернуть пустой контейнер.
Optional.of(value) в случае, если вы уверены, что значение, value, которое вы собираетесь положить в контейнер совершенно точно не null.
В противном случае используйте Optional.ofNullable(value).

Никогда не смешивайте null и Optional:

Optional<Object> optional = null; // Плохо!
Optional<Object> optional = Optional.of(null); // exception

Это путь в ад и к ненависти.

Подробно о Optional.

Доверяйте, но с аннотациями

К сожалению, в Java нет какого-то общего стандарта, и существует несколько видов аннотаций для этого, например:

javax.validation.constraints.NotNull
javax.annotation.Nonnull
org.jetbrains.annotations.NotNull
lombok.NonNull
org.eclipse.jdt.annotation.NonNull

Какую выбрать и как использовать?

Подробнее об этом тут и тут.

import javax.annotation.Nonnull;
import javax.annotation.Nullable;
import javax.annotation.ParametersAreNonnullByDefault;
import java.util.Objects;

@ParametersAreNonnullByDefault
public class Person {
    @Nonnull
    private final String name;

    @Nullable
    private final String email;

    private final int age;


    private Person(Builder builder) {
        this.name = Objects.requireNonNull(builder.name, "name");
        this.age = Objects.requireNonNull(builder.age, "age");
        this.email = builder.email;
    }

    public static Builder builder() {
        return new Builder();
    }

    @Nonnull
    public String getName() {
        return name;
    }

    public int getAge() {
        return age;
    }

    @Nullable
    public String getEmail() {
        return email;
    }

    public static class Builder {
        private String name;
        private Integer age;
        private String email;

        private Builder() {
        }

        public Builder setName(String name) {
            this.name = name;
            return this;
        }

        public Builder setAge(int age) {
            this.age = age;
            return this;
        }

        public Builder setEmail(@Nullable String email) {
            this.email = email;
            return this;
        }

        public Builder of(Person person) {
            this.name = person.name;
            this.age = person.age;
            this.email = person.email;
            return this;
        }

        public Person build() {
            return new Person(this);
        }
    }
}

Аннотация @ParametersAreNonnullByDefault на классе говорит о том, что все параметры в методах по умолчанию @Nonnull.

Но не возвращаемые значения!
Возвращаемые значения надо размечать вручную самому и явно.

Это довольно удобно и практично.

public void printStatus(@Nonnull String status) {
    // some code
}

printStatus(null);  // тот самый грузовик по встречной полосе

Заключение

Помните, что отсутствие значения у коллекции — это чаще всего пустая коллекция или пустой итератор.

Будьте аккуратнее со строками и boxing/unboxing!

Полезные ссылки

Null pointer в разных языках программирования
Спецификация Java про null
Про null
Когда использовать NonNull аннотации
Про проверки на null
Какие аннотации для null использовать
Про Optional
Java Optional — попытка избежать NullPoinerException
Ещё про Optional
Про Null.Часть 1
Про Null.Часть 2
Stop Abusing Nihil
Java. Проблема с null. Null safety.

Отдельная благодарность

Отдельную благодарность за ревью и помощь автор хочет выразить следующим людям из твиттера:

@norrittmobile
@thecoldwine
@mudasobwa
@dmi3vim
@ihavenoclue12

Источник