Есть ли причина НЕ использовать классы исключений, определенные в .NET Framework, в своем собственном коде?

Question

Итак, мы используем Блок приложения Enterprise Library 4.1 для обработки исключений для регистрации / обработки наших исключений в многопроектном приложении. У нас есть несколько пользовательских исключений, и мы выдаем некоторые исключения, классы которых определены в стандартных библиотеках классов .NET Framework (например, ArgumentException, InvalidOperationException, ArgumentNullException и т. Д.).

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

Мой вопрос: что не так с этим подходом? В то время я не мог указать на это пальцем, но он пах мне неправильно, и я не мог избавиться от своих беспокойных чувств по этому поводу. Меня беспокоит то, что на самом деле не так уж важно? Полагаю, это похоже на то, как хвост немного виляет собакой ...

Answer 1

Ик. Что мне не нравится в этом:

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

Я бы посоветовал руководству вашей команды прочесть пункт 60 из Effective Java 2nd edition . Да, речь идет о Java, а не о C #, но принципы остаются теми же.

Answer 2

Я повторяю ответы Джона Скита и Кева. Я бы просто добавил, что если ваша политика исключений хочет обрабатывать исключения уровня структуры, отличные от ваших собственных исключений, рассмотрите возможность использования трассировки стека исключений.

// Somewhere within a custom exception handler policy
var frame = new StackTrace(exception).GetFrame(0);
if (frame.GetMethod().DeclaringType.Namespace.StartsWith("MyNamespace.")) 
{
    // Handle exceptions from our code
}
else 
{
    // Handle framework-level exceptions
}

Answer 3

Книга Руководства по проектированию *1002* (первое издание) Кшиштофа Квалины и Брэда Абрамса рекомендует бросать существующие исключения, определенные в пространствах имен System, где можно, и чем конкретнее, тем лучше. Если не подходит, то выбрасывайте пользовательское исключение.

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

Это пахнет ненужной дополнительной работой для настоящего и будущего, когда речь идет о времени обслуживания кода.

Answer 4

Что ж, исключения, создаваемые вашим кодом и создаваемые базовыми классами .net, должны обрабатываться одинаково.

И то и другое, вероятно, является признаком проблемы в вашем коде, поэтому ни его не следует игнорировать или фильтровать!

Answer 5

Бросать исключения .Net - это хорошо, когда исключение правильно описывает тип проблемы, которую вы пытаетесь выявить (например, если аргумент нулевой, вы должны выбросить ArgumentNullException). Если вы обнаружите ситуацию, которая не обрабатывается платформой .Net (например, вы хотите разделить 6 на 3, но это не разрешено вашим приложением), вам следует создать собственное исключение.