Коли починати писати обробку винятків, ведення журналів

Коли ви починаєте писати свій Код обробки винятків? Коли ви починаєте писати протоколи журналів.

Для розробки цього питання припустимо, що ми перебуваємо на платформі .NET з log4net, але не соромтесь відповісти загальним способом.

Рішення: Проект Windows Forms. Проекти: інтерфейс користувача, BusinessRules, DataHandlers

Отже, чи збираєтеся ви писати свої DataHandlers, які виконують ваші маніпуляції з даними, такі як Створення, Читання, Оновлення, Видалення спочатку.

Потім дотримуйтесь його відповідно до Ваших правил бізнесу

А потім ваш інтерфейс користувача чи будь-яка інша перестановка вищезазначеного.

Перевірте свою програму на функціональність.

А потім почати писати свій Код обробки винятків і, нарешті, свій Реєстраційний код?

Коли настає правильний час, щоб почати писати свій код оброблення винятків?

PS: У книзі « Чистий код» вони кажуть: Напишіть спочатку свій пробний блок. Це спонукало мене до цього питання.

Ви пишете код обробки даних про винятки, коли ви пишете те, що викликає щось, що може спричинити винятки.

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

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

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

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

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

В іншому випадку ви виявите, що у вас є завдання для версії 2.0, такі як "Покращити обробку помилок" та "Створити систему ведення журналів". Вони будуть вирішені на користь нових функцій, і оскільки у вас "занадто багато робити", виправляючи всі ті помилки у випадках помилок, про які ви не думали. (Що займає вічно, тому що у вас немає системи реєстрації.

Залежить від того, що ти робиш

за винятками:

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

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

В будь-якому випадку, якщо ви не маєте нічого корисного з помилкою, подумайте про те, як пускати його в бульбашку (немає обробника)

для ведення журналу:

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

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

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

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

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

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