Подходы для Кода ошибки / Управление сообщениями в.NET
Поиск предложений/лучших практик на руководящих кодах ошибок и сообщениях в многоярусные приложения. Конкретно вещи как:
- Где коды ошибок должны быть определены? Перечисление? Класс?
- Как сообщения об ошибках или более подробная информация связаны с кодами ошибок? файлы ресурсов? атрибуты на перечислимых значениях, и т.д.?
- Если у Вас есть многоуровневое приложение, состоящее из DAL, BLL, UI и Общие проекты, например, должны там быть единственным гигантским списком кодов для всех уровней, или действительно ли коды расширяемы проектом/уровнем?
Обновление: Важный, чтобы упомянуть, что я не могу положиться только на Исключения и пользовательские Типы исключительной ситуации для сообщения об ошибке, поскольку некоторые клиенты для этого приложения будут через веб-сервисы (SOAP & REST)
Любые приветствующиеся предложения!
2 ответа
Коды ошибок - это старая школа, они понадобились вам в старые плохие времена программирования COM и C, среды, которые не поддерживали исключения. В настоящее время вы используете исключения для уведомления клиентского кода или пользователя о проблемах. Исключения в .NET информативны, у них есть тип, сообщение и диагностика.
Вам нужно различать два типа исключений: те, которые можно восстановить, и те, в которых вы не знаете, что именно пошло не так или как вы их устраняете. Последний вид наиболее распространен, вам понадобится человек, чтобы предпринять корректирующие действия. Для их возникновения используйте один из стандартных встроенных типов исключений .NET. IllegalOperationException, FormatException, ArgumentException являются общими вариантами. Если такое исключение вызывает серверная часть, вы просто хотите передать его без изменений. Обычно вам нужен блок finally, чтобы обеспечить согласованность вашего внутреннего состояния, иногда блок catch, который содержит простой бросок для восстановления состояния.
Все, что вы считаете восстанавливаемым, должно быть вызвано типом исключения, который вы объявляете самостоятельно, производным от класса Exception. Это дает исходному коду возможность написать предложение catch и сделать что-нибудь значимое. Вам нужно будет сгенерировать сообщение, описывающее проблему, в случае, если код восходящего потока на самом деле не обрабатывает ее, текст сообщения необходимо получить либо из жестко запрограммированной строки, либо из ресурса, если вы поддержка локализации.
Я думаю, что лучше создать общий проект (или проект ApplicationFramework) и поместить ваши исключения и общие объекты в него.
Это всегда хорошая идея иметь ApplicationFramework, который содержит базовый класс для ваших классов (особенно в UI - PageBase - MasterBase - ModuleBase и т.д.)
И как очевидно, вы должны поместить ваши классы и Enums в ваш BLL проект.
Обратите внимание, что 3 уровня не означает 3 проекта. Вы можете иметь 5 проектов в вашем BLL.
Наконец, не забудьте использовать ELMAH или другие подобные инструменты.