Вибір стратегії визначення виключень

Виключення повинні оброблятися однаково в усьому коді застосування. Для виявлення виключень використовуються блоки try, catch і finally. Виконува- ти перехоплення виключень рекомендується

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

Визначення стратегії поширення виключень

Залежно від вимог контексту, застосування може використати поєднання на- ступних стратегій :

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

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

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

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

Визначення необхідності використання власних виключень

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

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

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

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

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

Визначення збираних даних

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

1. Для кінцевих користувачів потрібно осмислений і добре представлений опис. При зборі даних виключення для кінцевих користувачів потрібно,

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

2. Розробникам застосування потрібні дані про точне місце виникнення виключення в коді, а також такі дані, як тип виключення і стан системи у момент виникнення виключення.

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

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