Найкращі практики створення шаблонів кодів помилок для корпоративного проекту в C # [закрито]

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

Які найкращі практики та рекомендації для цього?
Будь-яка допомога в цьому буде корисною.

Існує різниця між кодами помилок і значеннями повернення помилок. Код помилки призначений для користувача та довідкової служби. Значення повернення помилки - це техніка кодування, яка вказує на те, що у вашому коді сталася помилка.

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

Ось як я б це організував (зауважте, що пункти 2-6 - це мовні агностики):

1. Використовуйте спеціальний тип виключення з додатковим ErrorCodeвластивістю. Улов у головному циклі повідомить про це поле звичайним чином (файл журналу / помилка спливаюче вікно / відповідь про помилку). Використовуйте один і той же тип виключення у всьому коді.
2. Не починайте з 1 і не використовуйте провідні нулі. Зберігайте всі коди помилок однаковою довжиною, тому неправильний код помилки легко помітити. Починати з 1000 зазвичай досить добре. Можливо, додайте провідний "E", щоб зробити його чітко ідентифікованим для користувачів (особливо корисно, коли служба підтримки повинна вказувати користувачам, як визначити код помилки).
3. Зберігайте список усіх кодів помилок, але не робіть цього у своєму коді . Зберігайте короткий список на вікі-сторінці для розробників, який вони можуть легко редагувати, коли їм потрібен новий код. Довідкова служба повинна мати окремий список на власній вікі.
4. Не намагайтеся застосувати структуру на кодах помилок. Завжди буде важко класифікувати помилки, і ви не хочете годинами обговорювати, чи має бути помилка в групі 45xx або в групі 54xx. Будьте прагматичними .
5. Призначте кожен кидок у своєму коді окремим кодом. Незважаючи на те, що ви думаєте, що це одна і та сама причина, у службі довідки може знадобитися робити різні речі в різних випадках. Їм простіше мати "E1234: див. E1235" у своїй вікі, ніж змусити користувача визнати, що він зробив не так.
6. Розбити коди помилок, якщо служба довідки попросить цього. Простий if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");рядок у вашому коді може заощадити півтори години на довідковій службі.

І ніколи не забувайте, що мета кодів помилок - полегшити життя довідкової служби .

Спочатку потрібно виділити області, де можуть виникати помилки та видимі користувачеві. Потім ви можете їх документувати. Це так просто.

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

Тоді я б рекомендував двоступеневий підхід. По-перше, це вхід, лот і лоти.

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

Той самий підхід застосовується для веб-серверів та вашого прикладу коду помилки http. Якщо користувач бачить 404 і повідомляє його про підтримку, він шукатиме в журналах відомості про те, що відбувалося, яку сторінку відвідав, коли та отримає будь-яку іншу інформацію, яку вони зможуть, з будь-якого іншого сенсу. , бути в БД, мережі або додатку.

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