Как узнать, когда использовать существующее исключение или написать пользовательское исключение?

Question

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

Итак, теперь я создаю экземпляры своих классов с помощью этого кода:

try
{
    SmartForms smartForms = SmartForms.Create("ball");
    smartForms.Show();
}
catch (CannotInstantiateException ex)
{
    Console.WriteLine("Item could not be instantiated: {0}", ex.Message);
}

пользовательское исключение:

using System;

namespace TestFactory234.Exceptions
{
    class CannotInstantiateException : Exception
    {

    }
}

Как узнать, какой класс исключений использовать?

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

Или я что-то упускаю из-за исключений? Какие еще последствия имеют отношение к решению, какой тип исключения использовать?

Answer 1

Если причина, по которой вы не можете создать объект, заключается в том, что аргумент Create был недействительным, вам, вероятно, следует выдать ArgumentException. Однако вы всегда можете создать наш собственный класс, полученный из ArgumentException, если вы действительно хотите обрабатывать такого рода исключения отдельно от других. (Вы уверены, что хотите?)

Answer 2

Зачем создавать пользовательские исключения? довольно подробно объясняет, почему и когда использовать пользовательские исключения.

Answer 3

Написал целый пост на эту тему, который может вас заинтересовать

• http://blogs.msdn.com/jaredpar/archive/2008/10/20/custom-exceptions-when-should-you-create-them.aspx

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

Answer 4

Создайте новый тип, когда было бы полезно иметь возможность ловить и знать конкретный исключительный случай. Полезно ли знать, что файл не найден, а не общее исключение ввода-вывода?.

Answer 5

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

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

Answer 6

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

Как решить, создавать ли новое (полученное из Exception) или наследовать от существующего, зависит от того, что означает исключение.

Как говорит Джон, если ваш код выполняет некоторую проверку аргумента метода Create, вы можете захотеть сделать исключение из ArgumentException (например, может быть ArgumentNonExistentEntityException, если указанный идентификатор не существует хотя это полон рта).

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