Ще в кінці 90-х я досить багато працював з кодовою базою, яка використовувала винятки як контроль потоку. Він реалізував машину з кінцевим станом для управління програмами телефонії. Останнім часом мені нагадують ті дні, бо я робив веб-додатки MVC.

Вони обоє мають Controllerрішення, куди йти далі, і надаватимуть дані в логіку призначення. Дії користувачів із домену старого шкільного телефону, як тони DTMF, стали параметрами методів дій, але замість того, щоб повернути щось на зразок a ViewResult, вони кинули знак a StateTransitionException.

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

Це так, і якщо так, то чому?

Оновлення: коли я задав питання, я вже мав на увазі відповідь @ MasonWheeler, тому я пішов з відповіддю, яка найбільше додала до моїх знань. Я думаю, що його також є надійною відповіддю.

Докладне обговорення цього питання у Вікі Уорда . Як правило, використання винятків для управління потоком є анти-моделлю, з багатьма помітними ситуаціями - і для конкретної мови (див , наприклад , Python ) кашель виняток кашлю .

Як короткий підсумок, чому, як правило, це анти-шаблон:

• Виняток - це, по суті, складні заяви GOTO
• Програмування з винятками, таким чином, призводить до складності для читання та розуміння коду
• Більшість мов мають існуючі структури управління, розроблені для вирішення ваших проблем без використання винятків
• Аргументи ефективності, як правило, суперечать сучасним компіляторам, які, як правило, оптимізуються з припущенням, що виключення не використовуються для управління потоком.

Прочитайте дискусію на Вікі Уорда, щоб отримати більш детальну інформацію.

Дивіться також дублікат цього питання тут

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

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

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

Винятки такі потужні, як Продовження та GOTO. Вони є універсальною конструкцією потоку управління.

У деяких мовах вони є єдиною універсальною конструкцією потоку управління. Наприклад, JavaScript не має ні Продовження, ні GOTOнавіть не має належних викликів Tail. Отже, якщо ви хочете реалізувати складний потік управління в JavaScript, ви повинні використовувати Винятки.

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

Ви згадали про державні машини. SMs є тривіальною для реалізації за допомогою правильних викликів Tail: кожен стан є підпрограмою, кожен перехід стану - викликом підпрограми. SM-повідомлення також можуть бути легко реалізовані за допомогою GOTOабо Coroutines або Continuations. Однак, Java не має якогось - якого з цих чотирьох, але це дійсно є винятки. Отже, цілком прийнятно використовувати такі як контрольний потік. (Ну, насправді правильним вибором було б, мабуть, використання мови з правильною конструкцією потоку управління, але іноді ви можете застрягти з Java.

Як багато разів згадували інші ( наприклад, у цьому питанні щодо переповнення стека ), принцип найменшого здивування забороняє використовувати винятки надмірно для цілей контролю потоку. З іншого боку, жодне правило не є на 100% правильним, і завжди є випадки, коли виняток - це "правильний інструмент" - як і gotoсам, до речі, який постачається у формі breakта continueмовами, як Java, які часто є ідеальним способом вискочити з сильно вкладених петель, яких не завжди можна уникнути.

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

• http://blog.jooq.org/2013/04/28/rare-uses-of-a-controlflowexception

Це пояснює, як всередині jOOQ (бібліотеки абстракції SQL для Java) (відмова: я працюю для постачальника) такі винятки періодично використовуються для припинення процесу візуалізації SQL на ранніх термінах, коли виконується якась "рідкісна" умова.

Прикладами таких умов є:

• Зустрічається занадто багато значень прив'язки. Деякі бази даних не підтримують довільну кількість значень прив'язки у своїх операторах SQL (SQLite: 999, Ingres 10.1.0: 1024, Sybase ASE 15.5: 2000, SQL Server 2008: 2100). У цих випадках jOOQ перериває фазу візуалізації SQL і повторно надає оператор SQL з вбудованими значеннями прив’язки. Приклад:

  // Pseudo-code attaching a "handler" that will
  // abort query rendering once the maximum number
  // of bind values was exceeded:
  context.attachBindValueCounter();
  String sql;
  try {
  
    // In most cases, this will succeed:
    sql = query.render();
  }
  catch (ReRenderWithInlinedVariables e) {
    sql = query.renderWithInlinedBindValues();
  }
  

  Якщо ми явно дістали значення прив’язки з запиту AST, щоб їх підраховувати кожен раз, ми витратили б цінні цикли процесора на ті 99,9% запитів, які не страждають від цієї проблеми.

• Деяка логіка доступна лише опосередковано через API, який ми хочемо виконати лише "частково". UpdatableRecord.store()Метод генерує INSERTабо UPDATEзаяву, в залежності від Record«з внутрішніми прапорами. Ззовні ми не знаємо, яка саме логіка міститься store()(наприклад, оптимістичне блокування, обробка слухачем подій тощо), тому ми не хочемо повторювати цю логіку, коли ми зберігаємо кілька записів у пакетному операторі, там, де нам хотілося б store()генерувати лише оператор SQL, а не виконувати його. Приклад:

  // Pseudo-code attaching a "handler" that will
  // prevent query execution and throw exceptions
  // instead:
  context.attachQueryCollector();
  
  // Collect the SQL for every store operation
  for (int i = 0; i < records.length; i++) {
    try {
      records[i].store();
    }
  
    // The attached handler will result in this
    // exception being thrown rather than actually
    // storing records to the database
    catch (QueryCollectorException e) {
  
      // The exception is thrown after the rendered
      // SQL statement is available
      queries.add(e.query());                
    }
  }
  

  Якби ми розширили store()логіку на "повторно використаний" API, який можна налаштувати так, щоб необов'язково не виконувати SQL, ми б розглядали можливість створення досить важкого в обслуговуванні, важко повторного використання API.

Висновок

По суті, наше використання цих нелокальних gotos - це лише те, що сказав Мейсон Уілер у своїй відповіді:

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

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

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

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

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

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

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

Але може бути і покарання за виконання. Деякі мови мають більш-менш ефективну реалізацію оброблень виключень, тому якщо ваша обрана мова не має ефективного поводження з винятками, це може бути дуже дорогим та ефективним *.

Але інші мови, наприклад Ruby, мають синтаксис, що нагадує виняток для потоку управління. Виняткові ситуації обробляються з raise/ rescueоператорами. Але ви можете використовувати throw/ catchдля конструкцій керуючого потоку, подібних до винятків **.

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

* Приклад використання винятків, що дорого використовує продуктивність: колись я налаштований оптимізувати неякісний додаток для веб-форм ASP.NET. Виявилося, що візуалізація великої таблиці закликала int.Parse()ок. тисяча порожніх рядків на середній сторінці, в результаті чого прибл. обробляється тисяча винятків. Замінивши код на int.TryParse()я побрив одну секунду! Для кожного запиту на одну сторінку!

** Це може бути дуже заплутаним для програміста підходить до Рубі з інших мов, як throwі catchключові слова , пов'язані з винятками в багатьох інших мовах.

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

status = getValue(&inout);
if (status < 0)
{
    logError("message");
    return status;
}

doSomething(*inout);

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

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

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

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

Через відсутність багаторівневих перерв або оператора goto в Python, я часом використовував винятки:

class GOTO(Exception):
  pass

try:
  # Do lots of stuff
  # in here with multiple exit points
  # each exit point does a "raise GOTO()"
except GOTO:
  pass
except Exception as e:
  #display error

Давайте накреслимо таке використання виключення:

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

Окрім того, потрібен додатковий булевий found(щоб бути упакованим у клас, де в іншому випадку, можливо, був би повернутий лише інт), а для глибини рекурсії відбувається той самий постлюд.

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

Програмування - це робота

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

Кожен раз, коли викликається метод, абонент каже: "Я не знаю, як зробити цю роботу, але ви знаєте як", тому ви робите це для мене ".

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

Ранньою методологією довести це було просто повернути значення "сміття". Можливо, ви очікуєте додатне ціле число, тому викликаний метод повертає від’ємне число. Ще один спосіб досягти цього - десь встановити значення помилки. На жаль, обидва способи призвели до того, що кодовий код « перевірте-перевірте-тут-щоб переконатися» - це кошерний код. У міру ускладнення справи ця система розпадається.

Виняткова аналогія

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

Що б ви хотіли - це змусити його сказати вам: "Подивіться, я не зміг це виправити, тому що, здається, ваш насос не працює".

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

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

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

Отже ... антидіаграма?

Гаразд, тому розуміння точки винятків - це перший крок. Наступне - зрозуміти, що таке анти-шаблон.

Щоб кваліфікуватись як анти-модель, потрібно

• вирішити проблему
• мають остаточно негативні наслідки

Перший момент легко виконати - система спрацювала, правда?

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

Але це не остаточна шкода. Це поганий спосіб робити речі, і дивно, але анти-шаблон? Ні. Просто ... дивно.