Библиотека предварительных условий для выброса исключения IllegalArgumentException для проверки notNull

Поскольку тема этого вопроса превратилась в «Правильное использование IllegalArgumentException и NullpointerException», я хотел бы указать на прямой ответ в Effective Java Item 60 (второе издание):

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

А как насчет Preconditions checkArgument?

public void call(Person person) {
    Preconditions.checkArgument(person.getPhone() != null);
    // cally things...
}

checkArgument throws IllegalArgumentException вместо NullPointerException.

Вы можете использовать valid4j с hamcrest-matchers (найдены в Maven Central как org.valid4j: valid4j). Класс Validation поддерживает регулярную проверку ввода (т. Е. Выдачу восстанавливаемых исключений):

import static org.valid4j.Validation.*;

validate(argument, isValid(), otherwiseThrowing(InvalidException.class));

Ссылки:

• http://www.valid4j.org/
• https://github.com/valid4j/valid4j

На заметку: эта библиотека также поддерживает предварительные и пост-условия (например, утверждения), и при необходимости можно зарегистрировать свою собственную настраиваемую глобальную политику:

import static org.valid4j.Assertive.*;

require(x, greaterThan(0)); // throws RequireViolation extends AssertionError
...
ensure(r, notNullValue()); // throws EnsureViolation extends AssertionError

Взгляните на https://github.com/cowwoc/requirements.java/ ( Я автор). Вы можете переопределить тип исключения по умолчанию, используя withException() следующим образом:

new Verifiers().withException(IllegalArgumentException.class).requireThat(name, value).isNotNull();

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

class Preconditionz {
    public static <T> T checkNotNull(T reference, Object errorMessage) {
        if (reference == null) {
            throw new IllegalArgumentException(String.valueOf(errorMessage));
        }
        return reference;
    }
}

Мне нравится продолжать и import static эти действительно часто используемые методы, так что вы можете называть их очень кратко.

import static com.whatever.util.Preconditionz.checkNotNull;

// ...

public void call(Person person) {
    checkNotNull(person, "person");
    checkNotNull(person.getPhone(), "person.phone");
    // ...
}

В зависимости от вашей среды вы можете назвать его checkNotNull2, чтобы было проще добавить импорт через автозаполнение в вашу среду IDE или позволить вам использовать его вместе со стандартным checkNotNull.

Думаю, я снова кое-что узнал здесь, на SO, благодаря замечательным комментариям Оливье Грегуара, Луи Вассермана, CollinD и Captain Man. Стандарты обычно являются веской и достаточной причиной, поскольку они заставляют программистов на общеязыковых языках всегда понимать правильно, но в этом конкретном случае у меня было небольшое сомнение, что, возможно, это правило, установленное вокруг NPE, не слишком хорошо. Java - это старый язык, и некоторым его функциям не повезло (я не хочу ошибаться, возможно, это слишком строгое суждение) - например, отмечены исключения, хотя вы также можете не согласиться. Теперь я думаю, что это сомнение рассеялось и мне следует:

• Вызывайте исключение IllegalArgumentException, когда в конкретном контексте я могу сказать, почему нулевое значение неверно, а не с точки зрения бизнеса. Например, в методе обслуживания public void call(Person person) я знаю, что означает для системы, что номер телефона равен нулю.
• Вызывайте исключение NullPointerException, когда я просто знаю, что значение null здесь неверно и рано или поздно вызовет исключение NullPointerException, но в конкретном контексте я не знаю, что это означает с точки зрения бизнеса. Примером могут быть неизменяемые коллекции Guavas. Когда вы создаете такое и пытаетесь добавить элемент с нулевым значением, он выдает вам NPE. Он не понимает, что это значение означает для вас, это слишком общий характер, но он просто знает, что здесь неправильно, поэтому он решает также сказать вам это немедленно, с более подходящим сообщением, чтобы вы могли более эффективно распознать проблему.

Имея в виду вышеизложенное, я бы сказал, что лучший вариант сделать утверждение в примере public void call(Person person) - это то, что предлагает Капитан Человек:

Preconditions.checkArgument(person.getPhone() != null, "msg");

Проверить аргумент - хорошее название для этого метода - ясно, что я проверяю соответствие бизнес-контракта аргументу человека, и ясно, что я ожидаю исключения IllegalArgumentException в случае сбоя. Это имя лучше, чем Validate.isTrue из Apache Commons. С другой стороны, использование Validate.notNull или Preconditions.checkNotNull предполагает, что я проверяю нулевую ссылку и на самом деле ожидаю NPE.

Итак, окончательный ответ - такой красивой библиотеки не существует, и ее не должно быть, так как это сбивает с толку. (И Spring Assert надо поправить).

Вы легко можете это сделать:

if (person.getPhone() == null) {
    throw new IllegalArgumentException("Can't call a person that hasn't got a phone");
}

Другим программистам понятно, что вы имеете в виду, и они делают именно то, что вы хотите.