Рекомендации по созданию шаблона кодов ошибок для корпоративного проекта в C # [закрыто]

Я работаю над корпоративным проектом, который будет развернут во многих малых и средних предприятиях и предприятиях.
Поддержка этого проекта будет затруднена, и поэтому я хочу создать шаблон кодирования для ошибок (например, коды состояния HTTP ). Это позволит сотрудникам службы поддержки обращаться к документам и устранять проблемы как можно скорее.

Каковы лучшие практики и рекомендации для этого?
Любая помощь для этого будет полезна.

Существует разница между кодами ошибок и значениями ошибок. Код ошибки предназначен для пользователя и службы поддержки. Возвращаемое значение ошибки - это метод кодирования, указывающий, что в вашем коде обнаружена ошибка.

Можно реализовать коды ошибок, используя возвращаемые значения ошибок, но я бы посоветовал против этого. Исключения представляют собой современный способ сообщения об ошибках, и нет никаких причин, по которым они не должны содержать в себе код ошибки.

Вот как я бы это организовал (обратите внимание, что пункты 2-6 не зависят от языка):

1. Используйте пользовательский тип исключения с дополнительным ErrorCodeсвойством. Функция catch в основном цикле будет сообщать об этом поле обычным способом (файл журнала / всплывающее окно с ошибкой / ответ об ошибке). Используйте один и тот же тип исключения во всем вашем коде.
2. Не начинайте с 1 и не используйте начальные нули. Держите все коды ошибок одинаковой длины, чтобы можно было легко найти неправильный код ошибки. Начиная с 1000 обычно достаточно хорошо. Возможно, добавьте начальную букву «Е», чтобы их можно было легко идентифицировать для пользователей (особенно полезно, когда служба поддержки должна указывать пользователям, как распознать код ошибки).
3. Держите список всех кодов ошибок, но не делайте этого в своем коде . Держите короткий список на вики-странице для разработчиков, который они могут легко редактировать, когда им нужен новый код. Справочная служба должна иметь отдельный список в своей вики.
4. Не пытайтесь применять структуру кодов ошибок. Ошибки всегда будут трудно классифицировать, и вы не хотите часами обсуждать, должна ли ошибка быть в группе 45хх или в группе 54хх. Будьте прагматичны .
5. Назначьте каждому коду в вашем коде отдельный код. Даже если вы думаете, что это одна и та же причина, службе поддержки может потребоваться выполнить разные действия в разных случаях. Им легче иметь «E1234: Смотрите E1235» в своей вики, чем заставить пользователя признаться в том, что он сделал неправильно.
6. Разделите коды ошибок, если служба поддержки попросит об этом. Простая if (...) throw new FooException(1234, ".."); else throw new FooException(1235, "..");строка в вашем коде может сэкономить полчаса для справочной службы.

И никогда не забывайте, что цель кодов ошибок - облегчить жизнь службе поддержки .

Сначала вы должны изолировать области, где могут возникнуть ошибки, и которые видны пользователю. Тогда вы можете документировать их. Это так просто.

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

Я бы рекомендовал двухэтапный подход. Во-первых, чтобы войти, войти много и много.

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

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

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