2.11.1.Використання методів обробки події error в об'єктах

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

При передачі керування методу обробки події ERROR одночасно передаються три параметри.

Системний номер помилки.

Ім'я методу, при виконанні якого помилка виникла.

Номер рядка програмного коду, виконання якої привело до аварійної ситуації.

Від процедури обробки помилок, виконуваною виконавчою системою Visual FoxPro за замовчуванням, для користувача користі мало. Ця процедура виводить системне вікно повідомлення з номером помилки і чотирма кнопками. Перша з них — Cancel (Скасування). Якщо користувач клацне на ній, то поточна трансакція просто “зависне”. Якщо додаток виконується в середовищі Visual FoxPro, а не як автономне, можна вибрати кнопку Suspend, але незрозуміло, що ж користувачу робити після призупинення програми. Третя кнопка — Ignore. Ігнорувати помилку, звичайно, можна, але це, швидше за все, просто приведе до нової помилки. Залишається четвертий варіант — Help. Користувач одержить докладне пояснення, як подібна помилка взагалі може виникнути, але що йому робити в даній конкретній ситуації? З усього сказаного випливає тільки одне: не можна передоручати виконавчій системі таку важливу функцію, як обробка аварійної ситуації. Досить того, що вона може передати в цьому випадку керування тій процедурі, що ви самі для цього передбачите.

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

Технологія об'єктно-орієнтованого програмування дозволяє розробляти власні базові класи, у яких маються методи обробки помилок, тобто події ERROR. Потім можна формувати похідні від них — класи окремих екранних форм і т. п.

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

DODEFAULT(nError, cMethod, nLineNo)

Можна також і звернутися до методу ERROR() класу батьківського об'єкта-контейнера. У цьому випадку оператор виклику буде мати вид:

This.Parent.Error(nError, cMethod, nLineNo)

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

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

• Наскільки гостро цей додаток потрібен замовнику.

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

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

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

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