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

У мене є простий метод встановлення для властивості і nullне підходить для даної властивості. Мене завжди розривали в цій ситуації: чи варто кидати IllegalArgumentException, чи то NullPointerException? З боку javadocs, обидва здаються доречними. Чи є якийсь зрозумілий стандарт? Або це лише одна з тих речей, якими ви повинні робити все, що завгодно, і обидва справді правильні?

Здається, що IllegalArgumentExceptionзакликається, якщо ви не хочете nullбути дозволеним значенням, і NullPointerExceptionбуло б кинуто, якби ви намагалися використовувати змінну, яка виявляється такою null.

Ви повинні використовувати IllegalArgumentException(IAE), а не NullPointerException(NPE) з наступних причин:

По-перше, NPE JavaDoc чітко перераховує випадки, коли NPE підходить. Зауважте, що всі вони кидаються під час виконання при nullнеправильному використанні. На відміну від цього, IAE JavaDoc не міг бути більш зрозумілим: "Кинуто для вказівки на те, що метод був переданий незаконним або невідповідним аргументом". Так, це ти!

По-друге, коли ви бачите NPE у сліді стека, що ви припускаєте? Ймовірно, що хтось зневірив a null. Коли ви бачите IAE, ви припускаєте, що виклик методу у верхній частині стека передав незаконне значення. Знову ж таки, останнє припущення вірно, перше вводить в оману.

По-третє, оскільки IAE чітко розроблений для перевірки параметрів, ви повинні вважати це винятком вибору за замовчуванням, то чому б ви вибрали NPE? Звичайно, не для різної поведінки - чи дійсно ви очікуєте, що викликовий код буде ловити NPE окремо від IAE і робити щось інше? Чи намагаєтесь ви повідомити більш конкретне повідомлення про помилку? Але ви можете це зробити в тексті повідомлення про виключення, як і для всіх інших невірних параметрів.

По-четверте, всі інші невірні дані параметрів будуть IAE, так чому б не бути послідовними? Чому незаконний nullнастільки особливий, що заслуговує на окремий виняток від усіх інших видів незаконних аргументів?

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

Стандарт - кинути своє NullPointerException. Загально непогрішна "Ефективна Java" коротко обговорює це в пункті 42 (перша редакція), пункт 60 (друга редакція) або пункт 72 (третя редакція) "Вигідне використання стандартних винятків":

"Можливо, всі помилкові виклики методу зводяться до незаконного аргументу чи незаконного стану, але інші винятки стандартно використовуються для певних видів незаконних аргументів і станів. Якщо абонент передає нуль в якомусь параметрі, для якого нульові значення заборонені, конвенція диктує, що NullPointerException буде кинуто, а не IllegalArgumentException. "

Я був всім прихильником кидання IllegalArgumentExceptionнульових параметрів, до сьогодні, коли я помітив java.util.Objects.requireNonNullметод у Java 7. За допомогою цього методу замість того, щоб робити:

if (param == null) {
    throw new IllegalArgumentException("param cannot be null.");
}

Ви можете зробити:

Objects.requireNonNull(param);

і він кине а, NullPointerExceptionякщо параметр, який ви його передаєте, є null.

Зважаючи на те, що цей метод є правильним ударом в середині, java.utilя вважаю, що його існування є досить сильним свідченням того, що кидання NullPointerException- це "спосіб Java робити речі".

Я думаю, що я вирішив у будь-якому випадку.

Зауважте, що аргументи щодо жорсткої налагодження є неправдивими, оскільки ви, звичайно, можете надати повідомлення про NullPointerExceptionте, що було нульовим, і чому воно не повинно бути нульовим. Так само, як і з IllegalArgumentException.

Однією з додаткових переваг NullPointerExceptionє те, що в критичному коді з високою ефективністю ви можете відмовитись від явної перевірки на null (і NullPointerExceptionз дружнім повідомленням про помилку), і просто покластися на NullPointerExceptionавтоматичне отримання, коли ви зателефонуєте на метод null параметр. Якщо ви швидко зателефонуєте до методу (тобто швидко вийти з ладу), ви отримаєте по суті такий же ефект, просто не такий зручний для розробника. У більшості випадків, мабуть, краще перевірити явно і кинути корисне повідомлення, щоб вказати, який параметр був нульовим, але приємно мати можливість змінити це, якщо продуктивність диктує, не порушуючи опублікований контракт методу / конструктора.

Я схильний дотримуватися дизайну бібліотек JDK, особливо колекцій та одночасності (Джошуа Блох, Дуг Лі, ті хлопці знають, як створити надійні 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");  
    }  
}

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

Проголосував аргумент Джейсона Коена, оскільки він був добре представлений. Дозвольте мені розчленувати це крок за кроком. ;-)

• NPE JavaDoc прямо говорить, «інші незаконне використання об'єкта нульовий» . Якби це було лише обмеження ситуацій, коли час виконання зустрічається з нулем, коли цього не слід, усі такі випадки можна було б визначити набагато коротше.

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

• Я б обрав NPE над IAE з кількох причин

  • Він більш конкретний щодо характеру незаконної операції
  • Логіка, яка помилково дозволяє нулю, має тенденцію сильно відрізнятися від логіки, яка помилково допускає незаконні значення. Наприклад, якщо я перевіряю дані, введені користувачем, якщо я отримую неприйнятне значення, джерелом цієї помилки є кінцевий користувач програми. Якщо я отримаю нуль, це помилка програміста.
  • Недійсні значення можуть спричинити такі речі, як переповнення стека, помилки в пам'яті, винятки для розбору і т. Д. Дійсно, більшість помилок, як правило, в деякий момент є недійсним значенням у виклику методу. З цієї причини я бачу IAE як НАЙБІЛЬШЕ ЗАГАЛЬНІСТЬ усіх винятків під RuntimeException.

• Власне, інші недійсні аргументи можуть спричинити за собою всі інші винятки. UnknownHostException , FileNotFoundException , різноманітні винятки з помилок синтаксису, IndexOutOfBoundsException , збої аутентифікації тощо, тощо.

Взагалі, я вважаю, що NPE сильно злісний, тому що традиційно асоціюється з кодом, який не дотримується принципу невдачі . Це, плюс неспроможність JDK заповнити NPE рядком повідомлення, справді створило сильні негативні настрої, які недостатньо обґрунтовані. Дійсно, різниця між NPE та IAE з точки зору виконання - це суто назва. З цього погляду, чим точніше ви ставитеся до імені, тим більше ясності ви надаєте абоненту.

Це питання стилю "Священної війни". Іншими словами, обидві альтернативи хороші, але люди матимуть свої переваги, які вони захищатимуть до смерті.

Якщо це setterметод і nullпередається йому, я думаю, було б більше сенсу кинути IllegalArgumentException. NullPointerException, Здається, більше сенсу в тому випадку , коли ви намагаєтеся насправді використовувати null.

Таким чином, якщо ви використовуєте його , і це null, NullPointer. Якщо він передається в і це null, IllegalArgument.

Apache Commons Lang має NullArgumentException, який виконує ряд речей, обговорених тут: він розширює IllegalArgumentException, і його єдиний конструктор приймає назву аргументу, який повинен був бути недійсним.

Хоча я вважаю, що кидаючи щось на зразок NullArgumentException або IllegalArgumentException більш точно описує виняткові обставини, ми з колегами вирішили звернутися до порад Блоха з цього приводу.

Не міг більше погодитися з тим, що говориться. Невдача рано, невдача швидко. Досить гарна мантра винятку.

Питання про те, який Виняток кинути - це здебільшого питання особистого смаку. На мій погляд, IllegalArgumentException здається більш специфічним, ніж використання NPE, оскільки він говорить мені, що проблема була в аргументі, який я передав методу, а не зі значенням, яке може бути сформовано під час виконання методу.

Мої 2 центи

Насправді, питання про те, щоб кинути IllegalArgumentException або NullPointerException, на мій скромний погляд, є лише «святою війною» для меншості з неповноцінним розумінням поводження з винятками на Java. Загалом, правила прості та такі:

• Порушення обмеження аргументу повинні бути вказані якомога швидше (-> швидкий збій), щоб уникнути незаконних станів, які набагато важче налагодити
• у випадку недійсного нульового покажчика з будь-якої причини киньте NullPointerException
• у випадку незаконного індексу масиву / колекції, киньте ArrayIndexOutOfBounds
• у разі негативного розміру масиву / колекції, киньте NegativeArraySizeException
• у разі неправомірного аргументу, який не охоплений вище, і для якого у вас немає іншого більш конкретного винятку, киньте IllegalArgumentException як кошик для сміття
• з іншого боку, у випадку порушення обмежень у ПОЛІ, яке не вдалося уникнути швидким збоєм з якихось поважних причин, ловіть і повторно скидайте як IllegalStateException або більш конкретний перевірений виняток. Ніколи не дозволяйте в цьому випадку передавати оригінальні NullPointerException, ArrayIndexOutOfBounds тощо!

Існують щонайменше три дуже вагомі причини проти випадку відображення різного роду обмежень аргументів на IllegalArgumentException, третя, ймовірно, є такою серйозною, що відзначає поганий стиль практики:

(1) Програміст не може з упевненістю припустити, що всі випадки порушення обмежень аргументів призводять до IllegalArgumentException, оскільки велика більшість стандартних класів використовують цей виняток, а не як кошик для відходів, якщо немає більш конкретного виду виключень. Спроба відобразити всі випадки порушення обмежень аргументів на IllegalArgumentException у вашому API лише призводить до розчарування програміста з використанням ваших класів, оскільки стандартні бібліотеки здебільшого дотримуються різних правил, які порушують ваші, і більшість ваших користувачів API також використовуватимуть їх!

(2) Зображення винятків насправді призводить до різного роду аномалії, спричиненої єдиним успадкуванням: Усі винятки Java є класами, а тому підтримують лише єдине успадкування. Отже, не існує способу створити виняток, який справді кажуть і NullPointerException, і IllegalArgumentException, оскільки підкласи можуть успадковувати лише те чи інше. Закидання IllegalArgumentException у разі нульового аргументу, таким чином, користувачам API важче розрізняти проблеми, коли програма намагається програматично виправити проблему, наприклад, подаючи значення за замовчуванням у повтор виклику!

(3) Картографування фактично створює небезпеку маскування помилок. Для того, щоб відобразити порушення обмеження аргументів у IllegalArgumentException, вам потрібно буде кодувати зовнішній пробний прийом у кожному методі, який має обмежені аргументи. Однак просто ловити RuntimeException у цьому блоці вилову не виникає сумніву, оскільки це ризикує відображенням документованих RuntimeExceptions, кинутих методами libery, які використовуються у вашій формі, у IllegalArgumentException, навіть якщо вони не викликані порушеннями обмеження аргументів. Тож вам потрібно бути дуже конкретним, але навіть ці зусилля не захищають вас від випадків, коли ви випадково відобразите недокументований виняток виконання іншого API (тобто помилку) в IllegalArgumentException свого API.

З іншого боку, стандартна практика залишається простою, а виняток викликає незручність та конкретність. Для виклику методу правила також прості: - якщо ви зустрічаєтесь із задокументованим винятком виконання будь-якого виду, оскільки ви передали незаконне значення, або повторіть виклик із замовчуванням (для цього потрібні виключення), або виправте свій код - якщо з іншого боку, ви зазначаєте виняток під час виконання, яке не зафіксовано документально для заданого набору аргументів, подайте звіт про помилку виробникам методу, щоб переконатися, що або їх код, або їх документація виправлена.

Прийнята практика, якщо використовувати IllegalArgumentException (String message), щоб визначити параметр недійсним і дати якомога більше деталей ... Отже, щоб сказати, що параметри були визнані недійсними, а виняток - ненульним, ви б щось зробили подобається це:

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

У вас практично немає причин неявно використовувати "NullPointerException". NullPointerException - це виняток, викинутий віртуальною машиною Java при спробі виконання коду на нульовій посиланні (Like toString () ).

Викидання виключення, яке ексклюзивно для nullаргументів (незалежно від того, NullPointerExceptionчи спеціальний тип), робить автоматизоване nullтестування більш надійним. Це автоматизоване тестування може бути проведене з відображенням та набором значень за замовчуванням, як у Guava 's NullPointerTester. Наприклад, NullPointerTesterнамагатиметься викликати наступний метод ...

Foo(String string, List<?> list) {
  checkArgument(string.length() > 0);
  // missing null check for list!
  this.string = string;
  this.list = list;
}

... з двома списками аргументів: "", nullі null, ImmutableList.of(). Це дозволить перевірити, що кожен із цих дзвінків кидає очікуване NullPointerException. Для цієї реалізації проходження nullсписку не дає NullPointerException. Однак, трапляється, створюється, IllegalArgumentExceptionоскільки NullPointerTesterтрапляється використовувати рядок за замовчуванням "". Якщо NullPointerTesterочікує лише NullPointerExceptionна nullзначення, він ловить помилку. Якщо вона очікує IllegalArgumentException, вона її сумує.

Деякі колекції припускають, що nullвін відхилений, NullPointerExceptionа не IllegalArgumentException. Наприклад, якщо порівнювати набір, що містить nullнабір, який відхиляє null, перший набір зателефонує containsAllна другий і вловить його NullPointerException- але ні IllegalArgumentException. (Я дивлюся на реалізацію AbstractSet.equals.)

Ви можете обґрунтовано стверджувати, що використання неперевірених винятків таким чином є антипаттерном, що порівнювати колекції, що містять nullколекції, які не можуть містити, nullє ймовірною помилкою, яка справді повинна створити виняток, або що nullвзагалі внесення колекції є поганою ідеєю . Тим не менше, якщо ви не хочете сказати, що equalsв такому випадку викинете виняток, ви запам'ятаєте, що NullPointerExceptionпотрібно в певних обставинах, а не в інших. ("IAE перед NPE, за винятком після" c "...")

Як суб'єктивне питання це слід закрити, але оскільки воно все ще відкрите:

Це частина внутрішньої політики, яка застосовувалася в моєму попередньому місці роботи, і вона спрацювала дуже добре. Це все з пам'яті, тому я не можу згадати точне формулювання. Варто зазначити, що вони не використовували перевірені винятки, але це виходить за межі питання. Неперевірені винятки, які вони використовували, потрапили до 3 основних категорій.

NullPointerException: Не кидайте навмисно. NPE повинні бути викинуті тільки VM, коли винесе нульове посилання. Необхідно докласти всіх можливих зусиль для того, щоб вони ніколи не кидались. @Nullable і @NotNull слід використовувати разом з інструментами аналізу коду, щоб знайти ці помилки.

IllegalArgumentException: кидається, коли аргумент функції не відповідає публічній документації, щоб помилку можна було ідентифікувати та описати з точки зору переданих аргументів. Ситуація ОП потрапляла б у цю категорію.

IllegalStateException: кидається, коли функція викликається і її аргументи є або несподіваними в момент їх передачі, або несумісні зі станом об'єкта, членом якого є метод.

Наприклад, існували дві внутрішні версії IndexOutOfBoundsException, використовувані в речах, що мають довжину. Один підклас IllegalStateException, який використовується, якщо індекс був більшим за довжину. Інший підклас IllegalArgumentException, який використовується, якщо індекс був від'ємним. Це було тому, що ви можете додати більше об'єктів до об'єкта, і аргумент буде дійсним, тоді як від'ємне число ніколи не є дійсним.

Як я вже говорив, ця система працює дуже добре, і потрібно було комусь пояснити, чому це відмінність: "Залежно від типу помилки, вам зрозуміло, що робити. Навіть якщо ви насправді не можете зрозуміти, ви зрозумієте, що робити. щоб зрозуміти, що пішло не так, ви можете зрозуміти, де виправити цю помилку та створити додаткову інформацію про налагодження. "

NullPointerException: Обробіть справу Null або поставте твердження, щоб NPE не кидався. Якщо ви ставите твердження, це лише один з двох інших типів. По можливості продовжуйте налагодження, як ніби твердження там було в першу чергу.

IllegalArgumentException: у вас на сайті виклику щось не так. Якщо передані значення є з іншої функції, з’ясуйте, чому ви отримуєте неправильне значення. Якщо ви передаєте в одному з своїх аргументів розповсюдження, помилка перевіряє стек виклику, поки ви не знайдете функцію, яка не повертає очікуване.

IllegalStateException: Ви не викликали свої функції у правильному порядку. Якщо ви використовуєте один із своїх аргументів, перевірте їх і киньте IllegalArgumentException, що описує проблему. Потім ви можете розповсюджувати щоки проти стека, поки не знайдете проблему.

У будь-якому разі, його суть полягала в тому, що ви можете копіювати лише незаконні аргументиAssertions в стек. Ви не можете розповсюдити IllegalStateExceptions або NullPointerExceptions в стек, оскільки вони мали щось спільне з вашою функцією.

Взагалі розробник ніколи не повинен кидати NullPointerException. Цей виняток кидається під час виконання програми, коли код намагається знеструмити змінну, значення якої є нульовою. Тому, якщо ваш метод хоче явно заборонити null, на відміну від просто того, що має нульове значення підняти NullPointerException, вам слід кинути IllegalArgumentException.

Я хотів виділити Null аргументи з інших незаконних аргументів, тому я отримав виняток з IAE під назвою NullArgumentException. Навіть не потрібно читати повідомлення про виключення, я знаю, що нульовий аргумент передано у метод і, прочитавши повідомлення, я з’ясовую, який аргумент був недійсним. Я все ще ловлю NullArgumentException за допомогою обробника IAE, але в моїх журналах є те, де я швидко бачу різницю.

дихотомія ... Вони не перетинаються? Тільки неперекриваються частини цілого можуть скласти дихотомію. Як я бачу це:

throw new IllegalArgumentException(new NullPointerException(NULL_ARGUMENT_IN_METHOD_BAD_BOY_BAD));

NullPointerExceptionкидається при спробі отримати доступ до об'єкта з довідковою змінною, поточне значення якої становить null.

IllegalArgumentException кидається, коли метод отримує аргумент, відформатований інакше, ніж метод очікує.

За вашим сценарієм, IllegalArgumentExceptionце найкращий вибір, оскільки nullце не є дійсним значенням для вашої власності.

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

Визначення із посилань на два винятки вище: IllegalArgumentException: Кинуто, щоб вказати на те, що методу було передано незаконний або невідповідний аргумент. NullPointerException: кидається, коли програма намагається використовувати null у випадку, коли потрібен об'єкт.

Велика різниця тут полягає в тому, що IllegalArgumentException повинен використовуватися при перевірці того, що аргумент для методу є дійсним. NullPointerException повинен використовуватися, коли об'єкт "використовується", коли він є нульовим.

Я сподіваюся, що це допоможе поставити обох у перспективу.

Якщо це "сетер", або десь я отримую член для використання пізніше, я схильний використовувати IllegalArgumentException.

Якщо це я зараз буду використовувати (dereference) в методі, я кидаю NullPointerException проактивно. Мені це подобається краще, ніж дозволити виконувати це, тому що я можу надати корисне повідомлення (схоже, що час виконання також може зробити це, але це ще й інший день).

Якщо я переосмислюю метод, я використовую той, що використовується метод переопределення.

Вам слід кинути IllegalArgumentException, оскільки це дасть зрозуміти програмісту, що він зробив щось недійсне. Розробники настільки звикли бачити NPE, кинуту VM, що будь-який програміст не одразу усвідомить свою помилку, і почне оглядатись навмання, або ще гірше, звинувачує ваш код у тому, що він "баггі".

У цьому випадку IllegalArgumentException передає зрозумілу інформацію користувачеві за допомогою вашого API, що "не має бути нульовим". Як зазначають інші користувачі форуму, ви можете використовувати NPE, якщо хочете, якщо ви передаєте потрібну інформацію користувачеві за допомогою свого API.

GaryF і tweakt відкинули "Ефективну Java" (яку я клянусь) посиланнями, які рекомендує використовувати NPE. А дивлячись на те, як побудовані інші хороші API - це найкращий спосіб зрозуміти, як створити API.

Ще один хороший приклад - подивитися на API API Spring. Наприклад, org.springframework.beans.BeanUtils.instantiateClass (конструктор ctor, Object [] аргументи) має рядок Assert.notNull (ctor, "Конструктор не повинен бути нульовим"). org.springframework.util.Assert.notNull (Object object, String message) метод перевіряє, чи є переданий аргумент (об'єкт) нульовим, і якщо він передає нове IllegalArgumentException (повідомлення), яке потім потрапляє в org. метод springframework.beans.BeanUtils.instantiateClass (...).

Якщо ви вирішите викинути NPE і використовуєте аргумент у своєму методі, це може бути зайвим і дорогим, щоб явно перевірити наявність нуля. Я думаю, що ВМ вже робить це для вас.