Як я можу створювати та застосовувати контракти за винятками?

Я намагаюся переконати свою команду в тому, щоб дозволити використовувати винятки в C ++, а не повертати bool isSuccessfulабо enum з кодом помилки. Однак я не можу протистояти цій критиці його.

Розглянемо цю бібліотеку:

class OpenFileException() : public std::runtime_error {
}

void B();
void C();

/** Does blah and blah. */
void B() {
    // The developer of B() either forgot to handle C()'s exception or
    // chooses not to handle it and let it go up the stack.
    C();
};

/** Does blah blah.
 *
 * @raise OpenFileException When we failed to open the file. */
void C() {
    throw new OpenFileException();
};

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

2. Розглянемо розробник, який викликає C()функцію. Він не перевіряє документацію, тому не виключає жодних винятків. Виклик небезпечний і може зірвати програму у виробництві.

Але якщо ми перевіримо помилки таким чином:

void old_C(myenum &return_code);

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

Як я можу безпечно використовувати винятки, щоб був якийсь контракт?

Це правомірна критика винятків. Вони часто менш помітні, ніж прості поводження з помилками, такі як повернення коду. І немає простого способу примусового виконання «контракту». Частина полягає в тому, щоб ви могли перешкоджати виняткам на більш високому рівні (якщо вам доведеться виловлювати всі винятки на кожному рівні, чим він відрізняється від повернення коду помилки?). А це означає, що ваш код може викликати якийсь інший код, який не обробляє його належним чином.

Винятки мають і мінуси; ви повинні скласти випадок, виходячи із вартості та вигоди.
Ці дві статті я вважаю корисними: Необхідність винятків та Все, що не так, з винятками. Крім того, у цій публікації в блозі пропонується думка багатьох експертів щодо винятків з акцентом на C ++ . Хоча думка експертів, здається, схиляється на користь винятків, це далеко не явний консенсус.

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

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

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

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

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

Винятки призначені НЕ, щоб їх ловили всюди.

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

У моєму коді є лише декілька висловлювань про вилов - за межами основного циклу. І це, мабуть, є загальним підходом у сучасному C ++.

Винятки та коди повернення не є взаємовиключними.

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

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

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

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

Статична перевірка винятків не корисна.

Оскільки винятки не обробляються локально, зазвичай не важливо, які винятки можна кинути. Єдина корисна інформація - чи можна викинути якийсь виняток.

У Java є статична перевірка, але зазвичай це вважається невдалим експериментом, і більшість мов, оскільки - особливо C # - не мають такого типу статичної перевірки. Це добре прочитане про причини, чому C # не має цього.

З цих причин C ++ застаріло throw(exceptionA, exceptionB)на користь noexcept(true). За замовчуванням функція може кидати, тому програмісти повинні очікувати, що якщо документація прямо не передбачає іншого.

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

Я хотів би сказати, що написання безпечного коду виключення - це все, як уникнути написання обробників виключень!

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

Програмісти на C ++ не шукають специфікацій виключень. Вони шукають гарантії виключення.

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

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

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

Різні методи програмування на C ++ пропонують гарантії виключення. RAII (управління ресурсами на основі сфери) забезпечує механізм виконання коду очищення та забезпечення вивільнення ресурсів як у звичайних, так і у виняткових випадках. Створення копії даних перед виконанням модифікацій на об'єктах дозволяють відновити стан цього об’єкта, якщо операція не завершиться. І так далі.

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

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

Довідка: http://en.cppreference.com/w/cpp/language/exceptions#Exception_safety - див. Розділ Безпека виключень.

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

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

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

Довідка: http://www.gotw.ca/publications/mill22.htm

Починаючи з C ++ 17, [[nodiscard]]атрибут можна використовувати для повернення значень функції (див. Https://stackoverflow.com/questions/39327028/can-ac-function-be-declared-such-that-the-return-value -може бути ігнорованим ).

Отже, якщо я вніс зміну коду, і це вводить новий вид відмови (тобто новий тип винятку), чи це невід'ємна зміна? Чи повинно було змусити абонента оновити код або принаймні попередити про зміну?

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

Розглянемо розробника, який викликає функцію C (). Він не перевіряє документацію, тому не виключає жодних винятків. Дзвінок небезпечний

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

Якщо ви будуєте критичну систему, врахуйте, дотримуйтесь порад вашої команди та не використовуйте винятки. Це Правило 208 АВ у стандартах кодування повітряних транспортних засобів C ++ компанії «Локхід Мартін» . З іншого боку, рекомендації MISRA C ++ мають дуже специфічні правила щодо того, коли винятки можна і не можна використовувати, якщо ви будуєте програмну систему, сумісну з MISRA.

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

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