Малюнок 21. Діалогове вікно Event Tracking.

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

2.10.Використання Coverage Profiler

У Visual FoxPro 6 включений абсолютно новий компонент, що не має аналогів у попередніх версіях, — Coverage Profiler. Це, по суті, окремий додаток, використання якого представляє багатокроковий процес. Спочатку потрібно включити режим ведення протоколу покриття програми. Для цього в меню налагоджувальника потрібно вибрати ToolsCoverage Logging. Програма запросить ім'я файлу для збереження протоколу і режим запису у файл — Append (додати в кінець) чи Overwrite (писати поверх). Настроювання може бути виконана як таким способом, так і за допомогою спеціальної команди SET COVERAGE TO. Після цього можна запускати додаток на виконання. Коли виконання завершиться, виконаєте команду SET COVERAGE TO, але не вказуючи аргументу. У результаті передача інформації у файл протоколу припиниться.

Тепер можна запустити додаток Coverage Profiler. Це виконується або командою меню ToolsCoverage Profiler, або командою Visual FoxPro з вікна команд:

DO (_COVERAGE) WІTH <ім'я файлу протоколу покриття

Після цього ви побачите, що вікно розділиться на три панелі, як показано на Малюнок 22.

Малюнок 22. Додаток Coverage Profiler у режимі відображення покриття.

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

Замість режиму покриття (піктограма Coverage Mode) можна вибрати режим профілювання, для чого клацнути на піктограмі Profіle Mode на панелі інструментів. У цьому режимі в нижній панелі біля кожного оператора виводиться кількість звертань до нього, як показано на Малюнок 23.

2.11. Малюнок 23. Додаток Coverage Profiler у режимі відображення профілю. Використання процедур обробки помилок

На жаль, не існує способу пошуку і виправлення помилок, який би на всі 100% гарантував, що більше помилок у додатку немає. Завжди можна довести що у додатку є помилки – достатньо знайти хоча б одну, і неможливо довести, що їх немає – якщо їх ще не знайшли, то може погано шукали? Іноді додаток виявляється в ситуації, яку ніхто не міг собі представити при розробці. До того ж, кількість можливих комбінацій даних у нормальній системі настільки велика, що перебрати їх фізично майже неможливо. Крім того, існує ще одна особливість використання додатків: як би ви ні намагалися зробити систему “дуракостійкою”, вам не удасться домогтися стовідсоткового результату — дурні на диво винахідливі і, що саме небезпечне, ініціативні. Досить того, щоб один “винахідливий” користувач натиснув кнопку вимикання живлення на комп'ютері в той час, коли виконується реіндексація, — і десять мудреців одержать задоволення на тиждень, відновлюючи дані.

Таким чином, як це не сумно, потрібно прийняти як даність, що в програмі завжди існують помилки, що можуть привести до аварійної ситуації. У цьому випадку, якщо залишити обробку аварійної ситуації на розсуд виконавчої системи Visual FoxPro, просто буде виведено деяке повідомлення англійською мовою, що ще більш налякає користувача своєю таємничістю і незрозумілістю. Найчастіше, перш ніж викликати фахівця, користувач виключає комп'ютер і тим самим збільшує наслідки аварії. В аварійній ситуації потрібно, як мінімум, перенаправляти обробку помилок спеціальній процедурі, використовуючи тригер ON ERROR. Насамперед така процедура повинна зібрати інформацію про поточний стан програми і яким-небудь чином її зафіксувати. Приведена нижче команда передає керування в аварійній ситуації процедурі errlog.

ON ERROR DO errlog WITH ERROR(0, MESSAGE(0, MESSAGE(10, SYS(16), LINEN()))

Вже в процедурі можна визначити тип помилки по її номеру.

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

В інших випадках можна вивести користувачу просте вікно повідомлення і виконати команди RETRY чи RETURN. Прикладом може послужити ситуація, коли в програмі потрібно прочитати файл із гнучкого диска, а останній не вставлений у дисковод. Інший варіант — програмі потрібно записати дані на гнучкий диск, а на дискеті встановлений захист від запису. Тут дуже до речі буде вивести користувачу інструкцію, що йому потрібно зробити, і надати можливість після виправлення ситуації відновити виконання щигликом на кнопці RETRY (повторити).

Інший приклад. Припустимо, що при використанні команди SKІP (пропустити) для переміщення по записах користувач “проскочив” кінець таблиці. Visual FoxPro відреагує на це генерацією помилки типу End of file encountered (виявлений кінець файлу). Якщо бути точним, це помилка № 4. У такому випадку зовсім не потрібно переривати виконання програми. Для виправлення ситуації користувач може просто пересунути покажчик на останній запис таблиці. У наведеній процедури обробки помилок errlog, продемонстрована саме така методика.

PROCEDURE errlog

LPARAMETERS lnErrorNo, lcMess'age, lcErrorLine, lcmodule, lnErrorLineNo

* Якщо перехід за кінець файлу, установити покажчик на останньому запису

IF lnErrorNo = 4

WAIT WINDOW 'Записи скінчилися' TIMEOUT 2

GOTO BOTTOM

ELSE

CANCEL

ENDIF

RETURN

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

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

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

Більш серйозні помилки, що усе-таки не приводять до безнадійного краху системи, вимагають або більшої кількості обчислень, або залучення користувача для виходу із ситуації, що створилася. У процес відновлення можуть бути втягнуті і файли даних, і індекси. Іноді виявляється, що деякі файли переміщені куди-небудь чи узагалі вилучені. Таке найбільше ймовірно в мережних додатках. У цьому випадку програма припиняє роботу, як тільки не виявляє “на місці” потрібного файлу. Вибратися з такої ситуації можна, запропонувавши користувачу самостійно пошукати потрібний файл за допомогою системної функції GetFіle(). Це продемонстровано в наведеному нижче коду.

PROCEDURE errlog

LPARAMETERS lnErrorNo, lcMessage, lcErrorLine, lcModule, lnErrorLineNo

* Таблиця не використовується чи не знайдена

IF lnErrorNo = 1 OR lnErrorNo = 52

LOCAL lcNewFile

SELECT 0

lcNewFile = GETFILE ('DBF', 'Виберіть DBF:', 'SELECT')

IF EMPTY (lcNewFile)

CANCEL

ELSE

USE (lcNewFile) SHARED

IF lnErrorNo = 1

RETURN

ELSE

RETRY

ENDIF

ENDIF

ELSE

CANCEL

ENDIF

RETURN

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

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

Подивимося, що відбувається в системі далі, після того як користувач вибрав файл. Програма відкриває цей файл “і, якщо номер помилки був 1, передає оператором RETURN керування на оператор, який слідує відразу за оператором, що викликав помилку. У противному випадку (номер помилки 52) процедура повертає за допомогою RETRY керування тому оператору, у якому виникла помилка. Тепер починається нова спроба його виконати.

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