IllegalArgumentException или NullPointerException для нулевого параметра? [закрыто]

Стандарт должен бросить NullPointerException. Вообще безошибочный "Эффективный Java" обсуждает это кратко в Объекте 42 (первый выпуск), Объект 60 (второй выпуск), или Объект 72 (третий выпуск) "Способствует использованию стандартных исключений":

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

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

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

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

if( variable == null )
    throw new IllegalArgumentException("The object 'variable' cannot be null");

у Вас нет фактически причины неявно использовать "NullPointerException". NullPointerException является исключением, выданным виртуальной машиной Java, когда Вы пытаетесь выполнить код на нулевой ссылке (Как toString () ).

Если Вы принимаете решение бросить NPE, и Вы используете аргумент в своем методе, это могло бы быть избыточно и дорого явно проверить на пустой указатель. Я думаю, что VM уже делает это для Вас.

Если это - "метод set", или где-нибудь я заставляю участника использовать позже, я склонен использовать IllegalArgumentException.

, Если это - что-то, которое я собираюсь использовать (разыменовывают) прямо сейчас в методе, я бросаю NullPointerException заранее. Мне нравится это лучше, чем разрешение времени выполнения сделать это, потому что я могу обеспечить, полезное сообщение (кажется, что время выполнения могло сделать это также, но это - напыщенная речь в течение другого дня).

, Если я переопределяю метод, я использую то, что использует переопределенный метод.

Если бы это setter, метод и null передается ему, я думаю, что имело бы больше смысла бросать IllegalArgumentException. NullPointerException, кажется, имеет больше смысла в случае, где Вы пытаетесь на самом деле использовать null.

Так, при использовании его и это null, NullPointer. Если это передается в, и это null, IllegalArgument.

Не мог согласиться больше с тем, что говорится. Перестали работать рано, перестали работать быстро. Довольно хорошая молитва Исключения.

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

Мои 2 цента

В этом случае IllegalArgumentException передает ясную информацию пользователю, использующему Ваш API, который "не должен быть пустым". Поскольку другие пользователи форума указали, что Вы могли использовать NPE, если Вы хотите, пока Вы передаете правильную информацию пользователю, использующему Ваш API.

GaryF и tweakt отбросили "Эффективный Java" (которым я клянусь), ссылки, который рекомендует использовать NPE. И взгляд на то, как другие хорошие API создаются, является лучшим способом видеть, как создать Ваш API.

Другой хороший пример должен посмотреть на API Spring. Например, org.springframework.beans. BeanUtils.instantiateClass (Конструктор ctor, Объект [] args) имеет Assert.notNull (ctor, "Конструктор не должен быть пустым"), строка. org.springframework.util. Assert.notNull (Объектный объект, Строковое сообщение) проверки метода, чтобы видеть, передал ли аргумент (объект) в, являются пустыми и если это - он, бросает новый IllegalArgumentException (сообщение), которое тогда поймано в org.springframework.beans. BeanUtils.instantiateClass (...) метод.

Необходимо бросить IllegalArgumentException, поскольку он сделает его очевидным для программиста, что он сделал что-то недопустимое. Разработчики так привыкли к наблюдению NPE, брошенного VM, что любой программист сразу не осознал бы своей ошибки, и начнет озираться случайным образом, или хуже, обвинит Ваш код в том, что он был 'багги'.

Определениями от ссылок до этих двух исключений выше является IllegalArgumentException: Брошенный, чтобы указать, что метод был передан недопустимый или несоответствующий аргумент. NullPointerException: Брошенный, когда приложение пытается использовать пустой указатель в случае, где объект требуется.

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

я надеюсь, что это помогает поместить два в перспективу.

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

Я склонен следовать за дизайном библиотек JDK, особенно Наборы и Параллелизм (Joshua Bloch, Doug Lea, те парни знают, как разработать твердые API). Так или иначе, много API в JDK заранее бросает NullPointerException.

, Например, Javadoc для Map.containsKey состояния:

@throws NullPointerException, если ключ является пустым и эта карта, не разрешает пустые ключи (дополнительно).

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

шаблон идет:

public void someMethod(Object mustNotBeNull) {  
    if (mustNotBeNull == null) {  
        throw new NullPointerException("mustNotBeNull must not be null");  
    }  
}

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

Необходимо использовать IllegalArgumentException (IAE), не NullPointerException (NPE) по следующим причинам:

Первый, NPE JavaDoc явно перечисляет случаи, где NPE является соответствующим. Заметьте, что все они брошены временем выполнения , когда null используется неуместно. Напротив, IAE JavaDoc не мог быть более ясным: "Брошенный, чтобы указать, что метод был передан недопустимый или несоответствующий аргумент". Да, это - Вы!

В-третьих, так как IAE ясно разработан для проверки параметров, необходимо ли принять его как выбор по умолчанию исключения, итак, почему Вы выбрали бы NPE вместо этого? Конечно, не для различного поведения - Вы действительно ожидаете, что код вызова поймает NPE's отдельно от IAE и сделает что-то другое в результате? Вы пытаетесь передать более определенное сообщение об ошибке? Но можно сделать это в тексте сообщения об исключении так или иначе, как Вы должны для всех других неправильных параметров.

Четвертый, все другие неправильные данные параметра будут IAE, итак, почему бы не последовательный? Почему случается так, что нелегал null является столь особенным, что это заслуживает отдельного исключения из всех других типов недопустимых аргументов?

Наконец, я принимаю аргумент, данный другими ответами, что части API Java используют NPE этим способом. Однако API Java несовместим со всем от типов исключительной ситуации до соглашений о присвоении имен, таким образом, я думаю, просто вслепую копируя (Ваша любимая часть), API Java не является достаточно хорошим аргументом для превосхождения этих других соображений.