Глядя на код, отраженный от библиотек WCF, я вижу шаблон, используемый для создания исключений:Какова ценность фабрик Exception?
if(argument == null)
{
throw Error.ArgumentNull("argument");
}
Null аргументы будучи простейшим примером, с другими типами исключений, доступных через статический класс ошибок.
Какова ценность этого шаблона фабрики? Почему бы не использовать оператор new и просто вызвать конструктор ArgumentNullException?
Самая большая причина, по которой я нашел, - стандартизировать, как обрабатываются исключения и определяются ли они в рамках конкретной команды разработчиков (или команд). Даже Microsoft публикует, что различные типы исключений не являются стандартными между Exception, SystemException и ApplicationException. Возможно, что потребности в этом случае могут отличаться в зависимости от правил, определяющих конкретные логические случаи. Он также полезен для устранения общих задач (таких как ведение журнала) из повседневных проблем разработчика. Все, что разработчик должен сделать, это использовать соответствующее исключение на заводе, а завод позаботится об остальном.
Завод может выполнять дополнительную работу, например, журнал может быть исключением?
Он мог только регистрировать создание исключения. На этом этапе нет трассировки стека или какой-либо действительно полезной информации. –
@Programming Герой: он может _conceivably_ использовать класс 'StackTrace' для создания трассировки стека. Не то, чтобы это было. –
Я думаю, что основная причина заключается в том, что сообщения об исключениях .NET локализованы. Фактический текст сообщения должен быть извлечен из ресурса строки. Лучше поставить такой код в одном месте, чтобы никто не исказил имя ресурса строки.
Идея использования фабрики, позволяющая изменить тип фактического исключения, поражает меня как менее полезную. Это может сломать много клиентского кода, который по какой-то причине пытается поймать это исключение. Когда вы отправляете код, который генерирует конкретное исключение, вы в значительной степени зацикливаетесь на нем. Правильно выбирайте :)
Есть ли какие-либо примеры того типа стандартизации, о котором вы говорите? –
@Programming Hero - я имел в виду внутренние стандарты. Например, в нашей команде разработчиков здесь, на работе, мы (лидеры) собрались вскоре после того, как были назначены на наш первый проект, и хэшировали основы того, что мы хотели: стандарты именования, ведение журнала, обработка исключений, обработка событий, n-ярус архитектура и т. д. Мы сами не создавали фабрику, но мы указали в наших стандартах docs использование System.Exception вместо ApplicationException и стандартов, когда исключения должны регистрироваться, попадаться, обрабатываться или игнорироваться. –