Какой смысл в гуаве checkNotNull

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

public class Foo {
    private final String s;

    public Foo(String s) {
        this.s = s;
    }

    public int getStringLength() {
        return s.length();
    }
}

Допустим, вы не хотите разрешать нулевые значения для s. (иначе getStringLength выкинет NPE). С классом как есть, к тому времени, когда вы поймаете этот null, будет слишком поздно — очень трудно выяснить, кто его туда положил. Виновником вполне может быть совершенно другой класс, и этот экземпляр Foo мог быть сконструирован давным-давно. Теперь вам нужно прочесать свою кодовую базу, чтобы выяснить, кто мог поместить туда значение null.

Вместо этого представьте себе этот конструктор:

public Foo(String s) {
    this.s = checkNotNull(s);
}

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

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

public class StringLengthAverager {
    private int stringsSeen;
    private int totalLengthSeen;

    public void accept(String s) {
        stringsSeen++;
        totalLengthSeen += s.length();
    }

    public double getAverageLength() {
        return ((double)totalLengthSeen) / stringsSeen;
    }
}

Вызов accept(null) вызовет выброс NPE, но не раньше, чем stringsSeen будет увеличено. Это может быть не то, что вы хотите; как пользователь класса, я могу ожидать, что если он не принимает нули, то его состояние должно быть неизменным, если вы передадите нулевое значение (другими словами: вызов должен завершиться ошибкой, но он не должен сделать объект недействительным). Очевидно, в этом примере вы также можете исправить это, получив s.length() перед увеличением stringsSeen, но вы можете видеть, что для более длинного и сложного метода может быть полезно сначала проверить, что все ваши аргументы действительны, и только затем изменить состояние :

    public void accept(String s) {
        checkNotNull(s); // that is, s != null is a precondition of the method

        stringsSeen++;
        totalLengthSeen += s.length();
    }

myObject.getAnything(); (что может вызвать исключение NullPointerException, если myObject имеет значение null)

Нет... он будет вызывать NPE всякий раз, когда myObject == null. В Java нет возможности вызвать метод с null приемником (теоретически исключением являются статические методы, но их можно и нужно всегда вызывать без какого-либо объекта).

Я должен использовать checkNotNull(myObject).getAnything();

Нет, не следует. Это было бы довольно избыточно (Обновить).

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

В ответе yshavit упоминается важный момент: передавать недопустимое значение плохо, но хранить его и передавать позже еще хуже.

Обновлять

Фактически,

 checkNotNull(myObject).getAnything()

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

 myObject != null ? myObject.getAnything() : somethingElse

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

 myObject!!.getAnything()                    // checkNotNull
 myObject?.getAnything()                     // safe call else null
 myObject?.getAnything() ?: somethingElse    // safe call else somethingElse

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

Я прочитал всю эту ветку несколько минут назад. Тем не менее, я был сбит с толку, почему мы должны использовать checkNotNull. Затем просмотрите документ класса Precondition Guava, и я получил то, что ожидал. Чрезмерное использование checkNotNull определенно ухудшит производительность.

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

Согласно DOC: Ссылка

Использование чекнотнулл:

public static double sqrt(double value) {
     Preconditions.checkArgument(value >= 0.0, "negative value: %s", value);
     // calculate the square root
}

Предупреждение о производительности

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

if (value < 0.0) {
     throw new IllegalArgumentException("negative value: " + value);
}