Чи є змінні помилки антидіаграмою чи хорошим дизайном?

Щоб обробити кілька можливих помилок, які не повинні зупиняти виконання, у мене є errorзмінна, яку клієнти можуть перевіряти та використовувати для викидання винятків. Це анти-шаблон? Чи є кращий спосіб впоратися з цим? Для прикладу цього в дії ви можете побачити API mysqli PHP . Припустимо, що з проблемами видимості (доступними, публічними та приватними сферами - це змінна в класі чи глобальній?) Правильно обробляються.

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

Якщо у вас є вибір, ви можете використати винятки.

Повідомлення

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

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

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

Політику імені "foo" не вдалося отримати для користувальницької "бар", на яку посилалось у профілі користувача.

Порівняйте це із зворотним кодом -85. Якому б ви віддали перевагу?

Стеки викликів

Винятки зазвичай також мають детальні стеки викликів, які допомагають швидше та швидше налагоджувати код, і за потреби вони можуть реєструватися кодом виклику. Це дозволяє розробникам чітко визначити проблему в точній лінії, і, таким чином, є дуже потужним. Ще раз порівняйте це з файлом журналу із значеннями, що повертаються (наприклад, -85, 101, 0 тощо), який би ви хотіли?

Невдалий швидко упереджений підхід

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

Обгортка та розгортання винятків

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

Простота коду

Це трохи важче пояснити, але я дізнався за допомогою цього кодування як із поверненими значеннями, так і з винятками. Код, написаний за допомогою зворотних значень, зазвичай здійснював дзвінок, а потім проводив ряд перевірок того, що було значенням повернення. У деяких випадках він би викликав інший метод, і тепер буде проведена інша серія перевірок на значення, що повертаються з цього методу. За винятком, обробка винятків набагато простіша у більшості, якщо не у всіх випадках. У вас є блок "try / catch / нарешті", час виконання якого намагається виконати код, нарешті, блокує для очищення. Навіть вкладені блоки try / catch / нарешті порівняно простіше простежити та підтримувати, ніж вкладені if / else та пов'язані з ними значення повернення з декількох методів.

Висновок

Якщо платформа, яку ви використовуєте, підтримує винятки (наприклад, такі як Java або .NET), то вам слід обов'язково припустити, що немає іншого способу, окрім як викидати винятки, оскільки ці платформи мають вказівки щодо викидів винятків, і ваші клієнти збираються очікувати тому. Якщо я використовував вашу бібліотеку, я не буду намагатися перевіряти значення, що повертаються, тому що я очікую, що викиди будуть викинуті, ось такий світ у цих платформах.

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

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

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

Існує кілька способів подати сигнал про помилку:

• змінна помилка для перевірки: C , Go , ...
• виняток: Java , C # , ...
• обробник "умови": Lisp (тільки?), ...
• поліморфне повернення: Haskell , ML , Rust , ...

Проблема змінної помилки полягає в тому, що її легко забути перевірити.

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

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

Поліморфні повернення ( Either a bв Haskell) - це моє улюблене рішення поки що:

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

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

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

Ви отримуєте такий код:

String result = x.doActionA();
if (result != null) {
  throw new Exception(result);
}
result = x.doActionB();
if (result != null) {
  throw new Exception(result);
}

Або це:

if (!x.doActionA()) {
  throw new Exception(x.getError());
}
if (!x.doActionB()) {
  throw new Exception(x.getError());
}

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

x.doActionA();
x.doActionB();

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

Поточний (жахливий) код:

private String doActionA() {
  try {
    someOperationThatCanGoWrong1();
    someOperationThatCanGoWrong2();
    someOperationThatCanGoWrong3();
    return null;
  } catch(Exception e) {
    return "Something went wrong!";
  }
}

Нове та вдосконалене:

private void doActionA() throws Exception {
  someOperationThatCanGoWrong1();
  someOperationThatCanGoWrong2();
  someOperationThatCanGoWrong3();
}

Слідочок сліду зберігається і повідомлення доступне за винятком, а не марним "Щось пішло не так!".

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

"Щоб вирішити кілька можливих помилок, які не повинні зупиняти виконання",

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

Два шаблони, якими я користувався:

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

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

Те, що ви передаєте цим колекціям / обробникам, повинно містити достатній контекст, щоб помилка була оброблена "правильно" - Рядок, як правило, занадто мало, передаючи їй якийсь екземпляр винятку, часто розумно - але іноді нахмуриться (як зловживання винятками) .

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

class MyFunClass {
  public interface ErrorHandler {
     void onError(Exception e);
     void onWarning(Exception e);
  }

  ErrorHandler eh;

  public void canFail(int i) {
     if(i==0) {
        if(eh!=null) eh.onWarning(new Exception("canFail shouldn't be called with i=0"));
     }
     if(i==1) {
        if(eh!=null) eh.onError(new Exception("canFail called with i=1 is fatal");
        throw new RuntimeException("canFail called with i=2");
     }
     if(i==2) {
        if(eh!=null) eh.onError(new Exception("canFail called with i=2 is an error, but not fatal"));
     }
  }
}

Часто немає нічого поганого у використанні цього чи іншого шаблону, якщо ви використовуєте шаблон, який використовують усі інші. У розробці Objective-C значно кращим шаблоном є передача покажчика, де метод, який викликається, може депонувати об'єкт NSError. Винятки зарезервовані для помилок програмування та призводять до збоїв (якщо у вас немає програм Java або .NET, які пишуть свій перший додаток для iPhone). І це працює досить добре.

На питання вже відповіли, але я не можу собі допомогти.

Ви не можете реально очікувати, що виняток надасть рішення для всіх випадків використання. Молот кого?

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

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

Тож урок тут такий: Винятки мають свої місця, як і коди помилок. Вибирайте мудро.

Існують випадки використання, коли коди помилок є кращими за винятки.

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

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

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

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

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

У Perl 6 це робиться через fail, який у випадку, якщо no fatal;діапазон withing повертає спеціальний об'єкт виключення виключення Failure.

У Perl 5 ви можете використовувати Contextual :: Return, з яким ви можете це зробити return FAIL.

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

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

EDIT: Я не розумів, що це питання парадигми програмного забезпечення замість конкретного випадку.

Дозвольте мені уточнити свої моменти у конкретному моєму випадку, в якому моя відповідь мала б сенс

1. У мене є колекція об'єктів сутності
2. У мене є веб-сервіси процедурного стилю, які працюють з цими об'єктами сутності

Існує два види помилок:

1. Помилки під час обробки трапляються на рівні обслуговування
2. Помилки, оскільки в об'єктах сутності є невідповідності

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

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

• використовуючи змінну перевірки
• киньте виняток негайно, коли поле встановлено неправильно із сеттера

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

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