2009-06-09 3 views
2

Я ищу создание вспомогательного метода для установки сообщения об исключении, автоматически устанавливая String.Format, добавляя внутренние исключения, устанавливая коды выхода из командной строки и т. Д .; что-то вроде:Как создать помощников исключения?

public static void MyExceptionHelper(ExitCode code, string message) {} 
public static void MyExceptionHelper(ExitCode code, Exception e) {} 
public static void MyExceptionHelper(ExitCode code, Exception e, String message) {} 
public static void MyExceptionHelper(ExitCode code, Exception e, String message, params object[] args) {} 
// etc... 

BCL имеет несколько статических классов вокруг, что делает такого рода вещи (например, System.ThrowHelper в mscorlib).
Где лучше всего разместить их? Как перегруженные конструкторы исключения, в отдельном статическом классе (например, BCL), как статические методы для самого исключения или где-то еще?

ответ

1

Для таких методов я предпочитаю перегруженные конструкторы. Вы явно используете его для создания нового объекта, и для этого и нужен конструктор.

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

1

Я бы просто создал эти конструкторы для вашего класса исключения.

0

В большинстве случаев помощники исключения в BCL поддерживают локализацию (которая обычно завершается внутри внутреннего класса SR, который вы найдете почти во всех сборках .NET BCL.) Основная идея заключается в том, что вы используйте вспомогательный метод для передачи некоторых базовых данных для исключения, а помощник обрабатывает извлечение ресурсов и форматирование данных для создания исключения. Преимущество состоит в том, что вы централизуете код для исключений, которые могут быть выбраны из нескольких местоположений, но которые необходимо создать таким же образом. Как правило, такая же идея, как и любой другой класс утилит или унаследованный объект ... способствует повторному использованию и ремонтопригодности.

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

2

Я бы рекомендовал блок приложения Exception в EnterpriseLibrary, он имеет очень элегантный дизайн для работы с исключениями, и если вы не хотите, чтобы весь EntLib я рекомендовал копировать их интерфейс.

+0

Я согласен с тобой Марка –

0

Похоже, что у вас достаточно индивидуального поведения, чтобы вывести свой собственный класс исключений и поместить его на него. В зависимости от того, хотите ли вы взаимодействовать с базовым Exception sine qua Exception позже, вы можете захотеть, чтобы они были конструкторами на вашем производном классе, которые устанавливали базу в исключение в качестве исключения и выполняли ваши модификации в этом исключении из внутри вашего класса; полиморфизм позволит этому экземпляру быть восстановленным до базового Исключения для взаимодействия оттуда.

Смежные вопросы