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

Зараз у дискусії comp.lang.c ++ ведеться дискусія про те, чи слід твердження, які в C ++ існують лише у налагодженнях за замовчуванням, слід зберігати у виробничому коді чи ні.

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

Під твердженням я маю на увазі:

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

Я не обов'язково говорю про C або C ++.

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

Яка ваша думка / досвід?

Ура,

Карл

Дивіться відповідне запитання тут

Відповіді та оновлення

Гей, Грем,

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

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

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

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

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

Карл

Томас,

Так, у мене є Code Complete, і я повинен сказати, що я абсолютно не згоден з цією порадою.

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

Пам'ятайте, ми тут говоримо про товарний код, тому немає нарви на налагоджувач та перевірку місцевого стану. Це справжня помилка на машині користувача.

Карл

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

Дозвольте мені навести кодекс Стіва Макконнелла. Розділ про твердження - 8.2.

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

Однак пізніше в цьому ж розділі даються ці поради:

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

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

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

якщо це не варто вимірювати, щоб довести, що це більш ефективно, то не варто жертвувати ясністю для азартних ігор. "- Стів Макконнелл 1993

http://c2.com/cgi/wiki?ShipWithAssertionsOn

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

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

Більш цікаве питання таке: на етапі тестування, коли ви вимикаєте твердження?

Твердження ніколи не повинні залишатися у виробничому коді. Якщо певне твердження здається, що воно може бути корисним у виробничому коді, то воно не повинно бути твердженням; це повинно бути час виконання перевірки помилок, тобто що - то кодується таким чином: if( condition != expected ) throw exception.

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

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

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

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

У моєму C ++ я визначаю REQUIRE (x), який схожий на assrt (x), за винятком того, що він кидає виняток, якщо твердження не працює в версії версії.

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

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

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

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

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

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

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

Сказавши це, ми також намагаємось уникати тверджень про виробництво у критичних робочих процесах.

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

Я вважаю, що найкраще обробляти всі помилки, що знаходяться в обсягах, і використовувати твердження для припущень, які ми стверджуємо, ЩО ВИСТАЛЬНІ.

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

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

Ця функція readfile, в цьому контексті, і, напевно, відповідно до специфікації проекту, може припустити, що він отримає дійсний файл ptr. Отже, було б марно додавати код обробки помилок для негативного випадку в такій простої програмі. Однак слід хоча б документувати припущення, якось - переконатися якось --- що це насправді так, перш ніж продовжувати його виконання. Він не повинен ПРИСТУПНО припускати, що він завжди буде дійсним, якщо він викликаний неправильно, або копіюється / вставляється, наприклад, в якусь іншу програму.

Отже, readfile () {assert (fptr! = NULL); ..} доречно в цьому випадку, хоча повномасштабне поводження з помилками не є (ігнорування факту, що насправді для читання файлу все-таки знадобиться деяка система обробки помилок).

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

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

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

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

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

Я пропоную приклад

file = create-some-file();
_throwExceptionIf( file.exists() == false, "FILE DOES NOT EXIST");

проти

file = create-some-file();
ASSERT(file.exists());

Як додаток поводиться з твердженням? Я віддаю перевагу старому try catchметоду поводження зі смертельними помилками.

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

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

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

Є кілька моментів, щоб уникнути включення тверджень у виробничий код: 1. Ви не хочете, щоб ваш кінцевий користувач бачив повідомлення типу "ASSERTION не вдалося MyPrivateClass.cpp рядок 147. Кінцевий користувач НЕ ви QA інженер. 2. ASSERTION може впливати на продуктивність

Однак є одна вагома причина, щоб залишити твердження: ЗАСТОСУВАННЯ може вплинути на продуктивність та терміни, і, на жаль, це іноді має значення (особливо у вбудованих системах).

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

~ Іцик

Твердження є помилковим, чистим і простим, і тому слід поводитися як один.

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

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