Посібник C#, Налагодження коду
У C#, як і в інших мовах, що з'явилися до .NET, головна методика з налагодження полягає в додаванні точок зупинки і вивченні того, що відбувається в коді в конкретні моменти під час його виконання.
Точки зупинки
Якщо зупинка на певному рядку не підходить для вирішення наявної проблеми, можна створити так звану умовну точку зупинки. Для цього виберіть у меню Debug (Налагодження) пункт Windows --- Breakpoints (Вікно --- Точки зупинки). Відкриється діалогове вікно, що дозволяє вказати бажані деталі точки зупинки. У цьому вікні можна виконати такі дії:
Вказати, що виконання має перериватися лише після проходження точки зупинки певну кількість разів.
Вказати, що точка зупинки повинна вступати в дію при кожному n досягненні рядка, наприклад, при кожному 20-му її виконанні (це зручно при налагодженні великих циклів).
Задати точки зупинки щодо змінних, а чи не команд. У такому разі спостереження вестиметься за значенням зазначеної змінної, і точки зупинки активізуватимуться при кожній зміні значення цієї змінної. Однак цей варіант може сильно уповільнити виконання коду, оскільки на перевірку, чи не змінилося значення змінної, що відстежується після виконання кожної чергової інструкції, буде витрачатися додатковий час процесора.
Вкладка Autos дозволяє переглядати значення кількох останніх змінних, до яких здійснювався доступ у процесі виконання програми.
Вкладка Locals (Локальні) дозволяє переглядати значення змінних, до яких виходить доступ у методі, що виконується зараз.
Вкладка Watch (Стаження) дозволяє переглядати значення будь-яких змінних, що цікавлятьрахунок явної вказівки їхніх імен безпосередньо у вікні Watch.
Винятки
Винятки є чудовим засобом для забезпечення належної обробки помилок у додатку, що поставляється. У разі правильного застосування вони дозволяють отримати впевненість у тому, що програмі вдасться впоратися з труднощами, а перед користувачем ніколи не з'явиться діалогове вікно з технічним описом неполадки. На жаль, під час налагодження винятки не такі чудові. На те є дві причини:
Якщо виняток виникає під час налагодження, часто не потрібно, щоб воно оброблялося автоматично, особливо якщо це має на увазі акуратне завершення програми. Навпаки, відладчик повинен допомогти з'ясувати, чому виник цей виняток. Звичайно ж, складність полягає в тому, що у разі написання якісного надійного та відмовостійкого коду, програма автоматично оброблятиме практично все, у тому числі й неполадки, які потрібно виявити.
Якщо виник виняток, для якого не було передбачено оброблювача, середовище .NET, що виконує, все одно намагатиметься його знайти. На жаль, до моменту, коли вона виявить, що обробник немає, виконання програми буде завершуватися. Ніякого стека викликів, отже, не залишиться, і переглядати значення будь-яких змінних буде неможливо, тому що всі вони будуть за межами області видимості.
Звичайно, можна встановлювати точки зупинки в блоках catch, але це часто особливо не допомагає, оскільки при досягненні блоку catch потік управління визначення залишить відповідний блок try. Це означає, що змінні, значення яких, швидше за все, слід вивчити для з'ясування того, що пішло не так, залишать область видимості. Не буде навітьможливості переглядати трасувальні дані стека для з'ясування, який метод виконувався під час спрацьовування оператора throw, оскільки керування вже залишить цей метод. Зрозуміло, розміщення точки зупинки в операторі throw дозволить вирішити цю проблему, але треба враховувати, що при написанні коду захищеним чином операторів throw буде в коді дуже багато. Як тоді вгадати, який із них спрацьовує та призводить до генерації винятку?
Насправді Visual Studio пропонується дуже дієве рішення. Якщо заглянути вменю Debug (Налагодження), можна буде виявити там пункт Exceptions (Винятки). У разі вибору цього пункту відкривається діалогове вікно Exceptions (Винятки). Це вікно дозволяє вказувати, що має відбуватися при видачі винятку. Тут можна вказати, що виконання повинно продовжуватися або зупинятися з переходом в режим налагодження, в разі чого станеться зупинка, а відладчик виявиться прямо на самому операторі throw:
Visual Studio відомо про всі класи винятків, які доступні в базових класах .NET, і про багато таких винятків, які можуть видаватися за межами середовища .NET. Розпізнавати автоматично спеціальні класи винятків, створювані розробниками, Visual Studio не вміє, але дозволяє вручну додавати такі класи винятків до списку і, отже, вказувати, які з таких винятків повинні призводити до негайного припинення виконання програми. Для цього необхідно клацнути на кнопці Add (Додати), яка активізується при виборі верхнього вузла в дереві, та ввести ім'я спеціального класу виключення.
Додаткові команди налагодження вихідного коду
Компіляція практично всього комерційного програмного забезпечення на стадії налагодження та на стадіїПідготовка остаточної версії продукту повинна проводитися трохи по-різному. Середовище Visual Studio здатне це розуміти, оскільки зберігає інформацію про всі параметри, які їй належить передавати компілятору. Для підтримки різних варіантів компонування проекту Visual Studio потрібно зберігати подібну інформацію у більш ніж одному примірнику. Різні екземпляри такої інформації називаються конфігураціями. При створенні проекту Visual Studio автоматично пропонує на вибір дві такі конфігурації, які називаються відповідноDebug (Налагодження) таRelease (Випуск) :
Конфігурація Debug зазвичай вказує, що ніякі операції з оптимізації виконуватися не повинні, у коді, що виконується, повинна бути додаткова налагоджувальна інформація, а компілятор повинен припускати, що в коді визначено препроцесорний символ налагодження Debug, якщо тільки він не був явно скасований за допомогою директиви #undefined.
Конфігурація Release вказує, що компілятор повинен проводити щодо компілюваного коду оптимізацію, у виконуваному коді не повинно бути жодної додаткової інформації, а компілятор не повинен припускати наявність препроцесорного символу Debug.
Також можна визначати власні конфігурації. Це необхідно, наприклад, для компонування програми з декількома різними версіями. Раніше через проблеми, пов'язані з підтримкою кодування Unicode в Windows NT, але не в Windows 95, для багатьох проектів на С++ було прийнято створювати дві конфігурації – одну для Unicode, а другу для MBCS (multibyte character set – набір багатобайтних символів) ).