Чи слід перевірити зворотне значення виклику методу, навіть якщо я знаю, що метод не може повернути неправильний вхід?

Мені цікаво, чи варто захищати від зворотного значення виклику методу, підтверджуючи, що вони відповідають моїм очікуванням, навіть якщо я знаю, що метод, який я викликаю, відповідатиме таким очікуванням.

ПОДАРУТЬ

User getUser(Int id)
{
    User temp = new User(id);
    temp.setName("John");

    return temp;
}

ПОТРІБНО ЗРОБИТИ

void myMethod()
{
    User user = getUser(1234);
    System.out.println(user.getName());
}

АБО

void myMethod()
{
    User user = getUser(1234);

    // Validating
    Preconditions.checkNotNull(user, "User can not be null.");
    Preconditions.checkNotNull(user.getName(), "User's name can not be null.");

    System.out.println(user.getName());
}

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

Мій висновок з усіх відповідей (сміливо прийдіть до своїх):

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

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

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

Якщо ви якось точно знаєте, що getUser ніколи, ніколи, ніколи не зміниться у майбутньому, то так, це марно витрачати час на його перевірку, стільки ж, як витрачати час на перевірку часу, який iмає значення 3 одразу після i = 3;заяви. Насправді ви цього не знаєте. Але ви знаєте деякі речі:

• Ці дві функції "живуть разом"? Іншими словами, чи мають ті самі люди, що їх підтримують, чи є вони частиною одного файлу, і тому вони, ймовірно, залишаються "синхронізованими" один з одним? У цьому випадку, мабуть, надмірно додати перевірки перевірки, оскільки це означає лише більше коду, який повинен змінюватись (і потенційно нерегулярні помилки) щоразу, коли обидві функції змінюються або перетворюються на іншу кількість функцій.

• Чи є функція getUser частиною документально підтвердженого API з конкретним контрактом, а myMethod - лише клієнт вказаного API в іншій кодовій базі? Якщо це так, ви можете прочитати цю документацію, щоб дізнатися, чи слід перевіряти повернені значення (або попередньо перевірити вхідні параметри!) Чи дійсно безпечно сліпо слідувати щасливому шляху. Якщо документація цього не дає зрозуміти, попросіть технічне обслуговування виправити це.

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

Зауважте, що все вищесказане застосовується, навіть якщо ви є оригінальним автором обох функцій. Ми не знаємо, чи очікується, що ці дві функції "живуть разом" протягом усього життя, чи вони повільно розберуться на окремі модулі, чи ви хоч якось вистрілили себе в ногу з помилкою у старших версії getUser. Але можна, мабуть, зробити досить пристойну здогадку.

Відповідь Іксрека хороша, але я прийму інший підхід, оскільки вважаю, що варто задуматися. Для цілей цієї дискусії я розповім про твердження, оскільки це назва, за якою ваша Preconditions.checkNotNull()традиційно відома.

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

Мій девіз:

Питання, яке ви завжди повинні задавати собі, це не "чи варто це стверджувати?" але "чи я щось забув стверджувати?"

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

Але є навіть винятки з цього правила. Що цікаво, якщо взяти приклад Іксрека, існує така ситуація, коли цілком бажано дотримуватися int i = 3;твердження, яке iдійсно знаходиться в певному діапазоні. Це ситуація, коли iвін може бути змінений тим, хто намагається виконати різні сценарії "що-що", а наступний код покладається на iте, щоб мати значення в певному діапазоні, і це не очевидно, швидко переглянувши наступний код, що допустимий діапазон -. Таким чином, він застосовується машиною , тому він є ідеальною гарантією, і він переробляється разом з кодом , тому він залишається завжди доречним.int i = 3; assert i >= 0 && i < 5; може спочатку здатися безглуздим, але якщо ви подумаєте про це, це говорить про те, що ви можете грати i, а також говорить про те, в якому діапазоні ви повинні залишитися. Твердження - найкращий тип документації, оскільки

Ваш getUser(int id)приклад не дуже віддалений концептуальний родич цього assign-constant-and-assert-in-rangeприкладу. Ви бачите, за визначенням, помилки трапляються, коли речі виявляють поведінку, яка відрізняється від тієї поведінки, яку ми очікували. Щоправда, ми не можемо стверджувати все, тому іноді буде налагодження. Але це добре встановлений факт у галузі, що чим швидше ми виявляємо помилку, тим менше це коштує. Питання, які вам слід задати, полягають не лише в тому, наскільки ви впевнені, що getUser()ніколи не повернете нулеве значення (і ніколи не повернете користувача з нульовим іменем), але також і те, які погані речі відбудуться з рештою коду, якщо він буде Факт, одного дня повернеш щось несподіване, і як легко, швидко переглянувши решту коду, щоб точно знати, що від нього чекали getUser().

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

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

Певного немає.

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

Якщо потрібно перевірити будь-яку перевірку, кожна функція повинна перевірити власні пост-умови. Пост-умови дають вам впевненість, що ви правильно виконали функцію, і користувачі зможуть розраховувати на контракт вашої функції.

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

Якщо null є дійсним зворотним значенням методу getUser, то ваш код повинен обробляти це за допомогою If, а не винятку - це не винятковий випадок.

Якщо null не є дійсним значенням повернення методу getUser, то в getUser є помилка - метод getUser повинен викидати виняток або іншим чином виправлятись.

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

Я б заперечував, що передумова вашого запитання відключена: навіщо для початку використовувати нульове посилання?

Модель об'єкта нульового спосіб повернути об'єкти , які по суті нічого не робити: замість повернення NULL для вашого користувача, повертає об'єкт , який не представляє «немає користувача.»

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

Чому алгоритм повинен піклуватися про нульове значення? Етапи повинні бути однаковими. Так само просто і набагато зрозуміліше мати нульовий об'єкт, який повертає нуль, порожній рядок тощо.

Ось приклад перевірки коду на null:

User u = getUser();
String displayName = "";
if (u != null) {
  displayName = u.getName();
}
return displayName;

Ось приклад коду з використанням нульового об’єкта:

return getUser().getName();

Що зрозуміліше? Я вважаю, що другий.

Хоча питання позначено темою java , варто зазначити, що нульовий шаблон об'єкта дійсно корисний для C ++ при використанні посилань. Посилання на Java більше схожі на покажчики C ++, і дозволяють робити null. Посилання на C ++ не можуть містити nullptr. Якщо хотілося б мати щось аналогічне нульовій посиланню в C ++, єдиний спосіб я знаю, щоб це досягти.

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

1. надійність: чи може метод виклику впоратися зі nullзначенням? Якщо nullзначення може призвести до RuntimeExceptionя, рекомендую перевірити - якщо складність низька, а методи виклику / виклику створюються тим самим автором, і nullне очікується (наприклад, обидва privateв одному пакеті).

2. Відповідальність за код: якщо розробник A відповідає за getUser()метод, а розробник B використовує його (наприклад, як частину бібліотеки), я настійно рекомендую перевірити його значення. Просто тому, що розробник B може не знати про зміну, яка призводить до потенційного nullповернення.

3. складність: чим вище загальна складність програми чи середовища, тим більше я рекомендую перевірити повернене значення. Навіть якщо ви впевнені, що це не може бути nullсьогодні в контексті методу виклику, можливо, вам доведеться змінити getUser()інший випадок використання. Після того, як минули кілька місяців або років, і було додано кілька тисяч рядків кодів, це може бути досить пасткою.

Крім того, я рекомендую задокументувати потенційні nullзначення повернення у коментарі JavaDoc. Завдяки виділенню описів JavaDoc у більшості IDE, це може бути корисним попередженням для тих, хто використовує getUser().

/** Returns ....
  * @param: id id of the user
  * @return: a User instance related to the id;
  *          null, if no user with identifier id exists
 **/
User getUser(Int id)
{
    ...
}

Ви точно не повинні.

Наприклад, якщо ви вже знаєте, що повернення ніколи не може бути нульовим - навіщо ви хочете додати нульовий чек? Додавання нульової перевірки нічого не порушить, але просто зайве. І краще не кодувати зайву логіку, доки ви зможете її уникнути.