Чи повинні обмеження безпеки спричиняти повернення сервісу до нуля або викидання виключення? [зачинено]

Я трохи не погоджуюся з більш досвідченим розробником з цього питання, і мені цікаво, що про це думають інші; наше середовище - Java, EJB 3, послуги тощо.

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

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

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

Це нормальна та / або хороша практика? Я вважаю за краще використовувати винятки, бо мені набагато легше знати, що відбувається. Тому я, наприклад, також вважаю за краще кинути NotFoundException, якщо ви попросили об'єкт з недійсним ідентифікатором, а не повернути null.

Винятки слід кидати лише тоді, коли є помилка, а запитання про річ не є помилкою.

Просити щось може не помилка, але відсутність дозволів на те, про що ви просили, - це, безумовно, якась помилка. Винятки - це альтернативний спосіб повідомлення про виняткові умови, який слід використовувати замість спеціальних повернутих значень (таких як null, як ви писали, абсолютно не допомагає, якщо є> 1 можлива причина, чому все може піти не так (навіть якщо є Точно 1 можлива причина зараз, у наступній версії можуть бути 2 можливі причини, тому використання nullяк зворотного значення, що вказує на невдачу, буде малювати себе у кут)) Якщо служба жодним чином не повідомляє, чому вона не зробить те, про що ви просили, то це, безумовно, поганий дизайн.

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

String.substring()кидає, IndexOutOfBoundsExceptionякщо індекс не виходить за межі. Я не можу придумати жодних переваг для повернення nullзамість цього, хоча - по-філософськи - можна стверджувати, що те, Stringщо не містить нічого поза його межами, nullбуло б тоді логічним значенням повернення. Будучи логічно-філософськими та практичними - це, очевидно, дві різні тварини.

Це зводиться до того, яким є договір. Якщо у вашому договорі сказано, що ви можете запитати щось, що не існує, він повинен сказати, що відбувається (null або null object).

З іншого боку, якщо у вашому контракті сказано, що ви повинні спершу зателефонувати іншим методом ( DoesSomethingExist()), а потім викликати Getметод, тоді ваш контракт може сказати, що ви можете отримати лише ті речі, які існують, і викинути виняток, якщо цього немає. Повідомлення про виняток може сказати щось на зразок "Переконайтесь, щоб зателефонувати DoesSomethingExist()спочатку", що є корисним повідомленням про помилку.

На питання не існує однозначної відповіді. Буде використовувати винятки чи повернути нульове значення, залежить від ситуації.

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

Якщо абонент повинен знати, чому об’єкт не повертається, винятком є ​​виняток. Якщо, однак, загальне поняття "якщо ви не маєте дозволу, воно не існує", нуль є прийнятним.

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

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

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

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

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

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

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

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

Крім того, час, який ви витрачаєте на розуміння того, чому ви отримали нуль, є вагомим аргументом. Будь-який фрагмент коду повинен бути легким для розуміння та використання. Мати нульове значення - це не так.

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

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

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

Крім того, ви зрозуміли, що виникла проблема, тому що ви потрапили в інше місце NullPointerException. Тепер уявіть, що ви не зберігаєте повернення цієї функції ... Ви будете змушені оточувати кожен виклик цієї функції if elseблоком ...

З моєї точки зору, повернення null- погана практика.

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

З моєї точки зору, це не має сенсу.

Запит на дані без дозволу повинен спричинити виняток, оскільки це несподіваний результат - без результату - без належного доступу.

Аналогія : Відповідь на GETавторизацію без авторизації не 200 okмає даних, це насправді 401 Unauthorized.

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

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

Якщо першопричиною є неаутентифікований користувач, то я віддаю перевагу жорсткій відповіді HTTP 401, можливо, з перенаправленням на сторінку з симпатичними повідомленнями (та повідомлення для когось, кого це хвилює). Причини, пов’язані з авторизацією, є більш індивідуальними; є аргументи для повернення помилок HTTP (403, скажімо) та аргументи для повернення спеціальних добре сформованих кодів / повідомлень у відповіді служби.

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

Щоб грати в захисника чортів, я спробую стати на бік повернення нуля.

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

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

Візьмемо, наприклад, перевірку імені користувача та пароля. Повернення помилки "Ім'я користувача не знайдено" та "Неправильний пароль", оскільки окремі коди помилок очевидно відкриють вас до серйозних проблем безпеки, оскільки хтось може спочатку шукати дійсне ім'я користувача, а потім шукати пароль. Повернення загального "Недійсне ім'я користувача / пароль" було б кращим варіантом.

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

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