Аргументи за чи проти використання Try / Catch як логічних операторів [закрито]

Я щойно відкрив чудовий код у програмі наших компаній, яка використовує блоки Try-Catch як логічні оператори.
Значить, "зробіть якийсь код, якщо він видає цю помилку, зробіть цей код, але якщо це кине цю помилку, зробіть замість цього 3-ю річ".
Він використовує "Нарешті" як вислів "else", який з'являється.
Я знаю, що це по суті неправильно, але перед тим, як піти в бій, я сподівався на кілька добре продуманих аргументів.
І ей, якщо у вас є аргументи ЗА використання цього способу Try-Catch, будь ласка, скажіть.

Для всіх, хто цікавиться, мова - це C #, а код, про який йде мова, становить близько 30+ рядків і шукає конкретні винятки, він не обробляє ВСІ винятки.

Обробка винятків, як правило, є дорогим способом керування потоком (звичайно, для C # та Java).

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

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

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

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

Я щойно відкрив чудовий код у програмі наших компаній, яка використовує блоки Try-Catch як логічні оператори. Значить, "зробіть якийсь код, якщо він видає цю помилку, зробіть цей код, але якщо це кидає цю помилку, зробіть замість цього 3-ю річ". Він використовує "Нарешті" як вислів "else", який з'являється. Я знаю, що це властиво неправильно ...

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

try { 
    return Optional.of(Long.valueOf(s)); 
} catch (NumberFormatException) { 
    return Optional.empty(); 
}

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

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

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

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

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

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

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

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

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

Я бачив цю схему, яку використовували кілька разів.

Є дві основні проблеми:

• Це надзвичайно дорого (інстанція об'єкта виключення, збирання стека викликів тощо). Деякі компілятори можуть насправді оптимізувати його, але я б не розраховував на це в цьому випадку, оскільки винятки не призначені для такого використання, тому ви не можете очікувати, що люди оптимізують його.
• Використання винятків для контрольного потоку насправді є стрибком, як і goto. Стрибки вважаються шкідливими з ряду причин. Їх слід використовувати, якщо всі альтернативи мають значні недоліки. Насправді, у всьому своєму коді я згадую лише 2 випадки, коли стрибки були явно найкращим рішенням.

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

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

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

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

1. Випадкове ковтання вкладених винятків. Це головне. Якщо ви потрапили на якийсь глибоко вкладений виняток, з яким намагається вчинити хтось інший, ви просто застрелили свого колегу-програміста (можливо, навіть ви!) У ногу.
2. Тести стають неочевидними. Блок коду, у якому є виняток, може мати одну з декількох речей, що не так. З іншого боку, булева ситуація, хоча теоретично це може дратувати налагодження, це, як правило, не так. Це особливо вірно, оскільки try...catchприхильники потоку управління загалом (на мій досвід) не дотримуються філософії "мінімізувати код у пробному блоці".
3. Це не дозволяє else ifблокувати. Досить сказано (і якщо хтось зустрічається з "Але вони могли використовувати різні класи винятків", моя відповідь "Зайдіть у свою кімнату і не виходьте, поки не подумаєте про те, що ви сказали".)
4. Це граматично вводить в оману. Exception, для решти світу (як і для не прихильників try...catchфілософії контрольного потоку) означає, що щось увійшло в нестабільний (хоча можливо, відновлений) стан. Нестабільні стани - БАД, і це повинно нас тримати в ночах, якщо насправді є виключення, які можна уникнути (це насправді повзує мене, немає брехні).
5. Він не відповідає загальному стилю кодування. Наша робота, як з нашим кодом, так і з нашим інтерфейсом, полягає в тому, щоб зробити світ максимально очевидним. try...catchконтрольний потік суперечить тим, що зазвичай вважається найкращими методами. Це означає, що знадобиться більше часу, щоб хтось новий у проекті вивчив проект, а це означає збільшення кількості людино-годин за абсолютно ніякого прибутку.
6. Це часто призводить до дублювання коду. Нарешті блоки, хоч це і не є строго необхідним, потрібно вирішити всі звисаючі покажчики, які залишилися відкритими перерваним блоком спробу. Тому спробуйте блоки. Це означає, що ви можете мати try{ obj.openSomething(); /*something which causes exception*/ obj.doStuff(); obj.closeSomething();}catch(Exception e){obj.closeSomething();}. За більш традиційним if...elseсценарієм, closeSomething()менша ймовірність (знову ж таки, особистий досвід) буде копіювати та вставляти завдання. (Правда, цей конкретний аргумент більше стосується людей, яких я зустрів, ніж власне філософії).

Мій головний аргумент полягає в тому, що використання try / catch для логіки порушує логічний потік. Дотримуватися «логіки» через нелогічні конструкції (для мене) контрінтуїтивно та заплутано. Я звик читати свою логіку як "якби стан, то інший B". Читання того самого твердження, що і "Спробуйте зловити, тоді виконайте B", виглядає дивно. Було б навіть дивніше, якщо оператор A- це просте завдання, вимагаючи додаткового коду, щоб примусити виняток, якщо conditionвін помилковий (і для цього, ймовірно, потрібен буде ifзаява в будь-якому разі).

Ну, лише питання етикету, перед тим, як "розпочати з ними суперечку", я, як ви заявляєте, запитав "Чому вони використовують обробку виключень у всіх цих різних місцях?"

Я маю на увазі, є кілька можливостей:

1. вони некомпетентні
2. є цілком поважна причина того, що вони зробили, яке може не з’явитися з першого погляду.
3. іноді це питання смаку і може спростити деякий складний потік програми.
4. Це пережиток минулого, яке ще ніхто не змінив, і вони будуть раді, якщо хтось це зробить

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

Спробуйте Catch слід використовувати лише для обробки виключень. Тим більше, що специфічна обробка виключень. Ваш спробу лову повинен охоплювати лише очікувані винятки, в іншому випадку він недостатньо сформований. Якщо вам потрібно скористатися уловом, будь-який спробувати, то ви, ймовірно, робите щось не так.

Редагувати:

Причина: Ви можете стверджувати, що якщо ви використовуєте спробу catch в якості умовного оператора, то як ви збираєтеся враховувати РЕАЛЬНІ винятки?

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

Причина використовувати винятки:

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

Причини не використовувати винятки:

1. Багато мов не розроблені для швидкого винятку.
2. Винятки, які пересуваються на кілька шарів до стека, можуть залишати непослідовний стан

Наприкінці:

Мета - написати код, який повідомляє, що відбувається. Винятки можуть допомогти / перешкодити цьому залежно від того, що робить код. Спроба / лов у python для KeyError у довіднику словника ідеально (доки ви знаєте мову) спробувати / ловити для того самого KeyError, що знаходиться п’ятьма функціональними шарами, є небезпечним.

Я використовую try-> catch як контроль потоку в певних ситуаціях. Якщо ваша основна логіка залежить від того, що виходить з ладу, але ви не хочете просто кинути виняток і кинути ... Це те, для чого потрібен блок "try-> catch". Я пишу безліч непідконтрольних unix-скриптів на стороні сервера, і для них набагато важливіше, щоб вони не вийшли з ладу, ніж це, щоб вони вийшли з ладу.

Тому спробуйте план A, і якщо план A загине, ловіть і запускайте план B ... І якщо план B не вдається, скористайтеся, нарешті, для того, щоб почати план C, який або виправить одну з невдалих служб у A або B, або я.

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

Це погана звичка, але я це час від часу роблю в пітоні. Як і замість перевірки, чи існує файл, я просто намагаюся його видалити. Якщо це кидає виняток, я ловлю і просто рухаюся, знаючи, що його там не було. <== (не обов'язково істинно, якщо інший користувач є власником файлу, але я це роблю в домашній каталог користувача, щоб це НЕ МОЖЕ відбуватися).

І все-таки, надмірне використання - це погана практика.

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

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

З багатьох причин, чому логіка goto погана, ви можете звернутися до цього питання: https://stackoverflow.com/questions/46586/goto-still-considered-harmful