Какие исключения должны быть выданы для недопустимых или неожиданных параметров в.NET?

Я проголосовал за ответ Джоша , но хотел бы добавить еще один в список:

System.InvalidOperationException должно быть выброшено, если аргумент допустим, но объект находится в состоянии, в котором аргумент не должен использоваться.

Update Взято из MSDN:

InvalidOperationException используется в случаи, когда неспособность вызвать Метод вызван причинами, отличными от неверные аргументы.

Допустим, у вашего объекта есть метод PerformAction (действие enmSomeAction), допустимыми являются enmSomeActions Open и Close. Если вы вызываете PerformAction (enmSomeAction.Open) два раза подряд, то второй вызов должен вызвать исключение InvalidOperationException (поскольку arugment был действителен, но не для текущего состояния элемента управления)

, поскольку вы уже делаете правильные вещи при программировании для защиты я должен упомянуть еще одно исключение - ObjectDisposedException. Если ваш объект реализует IDisposable, тогда у вас всегда должна быть переменная класса, отслеживающая состояние удаления; если ваш объект был удален и для него вызван метод, вы должны вызвать исключение ObjectDisposedException:

public void SomeMethod()
{
    If (m_Disposed) {
          throw new ObjectDisposedException("Object has been disposed")
     }
    // ... Normal execution code
}

Обновление: Чтобы ответить на ваши последующие действия: Это немного двусмысленная ситуация, и усложняется общим (не в смысле .NET Generics) типом данных, используемым для представления определенного набора данных; перечисление или другой строго типизированный объект были бы более идеальным соответствием - но у нас не всегда есть этот элемент управления.

Я лично склонялся бы к ArgumentOutOfRangeException и предоставил бы сообщение, которое указывает, что допустимые значения 1-12. Я рассуждаю так: когда вы говорите о месяцах, предполагая, что все целочисленные представления месяцев действительны, то вы ожидаете значение в диапазоне 1-12. Если бы действовали только определенные месяцы (например, месяцы, в которых было 31 день), вы бы не имели дело с самим диапазоном, и я бы выдал обобщенное исключение ArgumentException, в котором указаны действительные значения, и я также задокументировал бы их в комментариях метода.

NET Generics смысле) тип данных, используемый для представления определенного набора данных; перечисление или другой строго типизированный объект были бы более идеальным соответствием - но у нас не всегда есть этот элемент управления.

Я лично склонялся бы к ArgumentOutOfRangeException и предоставил бы сообщение, которое указывает, что допустимые значения 1-12. Я рассуждаю так: когда вы говорите о месяцах, предполагая, что все целочисленные представления месяцев действительны, то вы ожидаете значение в диапазоне 1-12. Если бы действовали только определенные месяцы (например, месяцы, в которых было 31 день), вы бы не имели дело с самим диапазоном, и я бы выдал обобщенное исключение ArgumentException, в котором указаны действительные значения, и я также задокументировал бы их в комментариях метода.

NET Generics смысле) тип данных, используемый для представления определенного набора данных; перечисление или другой строго типизированный объект были бы более идеальным соответствием - но у нас не всегда есть этот элемент управления.

Я лично склонялся бы к ArgumentOutOfRangeException и предоставил бы сообщение, которое указывает, что допустимые значения 1-12. Я рассуждаю так: когда вы говорите о месяцах, предполагая, что все целочисленные представления месяцев действительны, то вы ожидаете значение в диапазоне 1-12. Если бы действовали только определенные месяцы (например, месяцы, в которых было 31 день), вы бы не имели дело с самим диапазоном, и я бы выдал обобщенное исключение ArgumentException, в котором указаны действительные значения, и я также задокументировал бы их в комментариях метода.

перечисление или другой строго типизированный объект были бы более идеальным соответствием - но у нас не всегда есть этот элемент управления.

Я лично склонялся бы к ArgumentOutOfRangeException и предоставил бы сообщение, которое указывает, что допустимые значения 1-12. Я рассуждаю так: когда вы говорите о месяцах, предполагая, что все целочисленные представления месяцев действительны, то вы ожидаете значение в диапазоне 1-12. Если бы действовали только определенные месяцы (например, месяцы, в которых было 31 день), вы бы не имели дело с самим диапазоном, и я бы выдал обобщенное исключение ArgumentException, в котором указаны действительные значения, и я также задокументировал бы их в комментариях метода.

перечисление или другой строго типизированный объект были бы более идеальным соответствием - но у нас не всегда есть этот элемент управления.

Я лично склонялся бы к ArgumentOutOfRangeException и предоставил бы сообщение, которое указывает, что допустимые значения 1-12. Я рассуждаю так: когда вы говорите о месяцах, предполагая, что все целочисленные представления месяцев действительны, то вы ожидаете значение в диапазоне 1-12. Если бы действовали только определенные месяцы (например, месяцы, в которых было 31 день), вы бы не имели дело с самим диапазоном, и я бы выдал обобщенное исключение ArgumentException, в котором указаны действительные значения, и я также задокументировал бы их в комментариях метода.

Я рассуждаю так: когда вы говорите о месяцах, предполагая, что все целочисленные представления месяцев действительны, то вы ожидаете значение в диапазоне 1-12. Если бы действовали только определенные месяцы (например, месяцы, в которых было 31 день), вы бы не имели дело с самим диапазоном, и я бы выдал обобщенное исключение ArgumentException, в котором указаны действительные значения, и я также задокументировал бы их в комментариях метода.

Я рассуждаю так: когда вы говорите о месяцах, предполагая, что все целочисленные представления месяцев действительны, то вы ожидаете значение в диапазоне 1-12. Если бы действовали только определенные месяцы (например, месяцы, в которых было 31 день), вы бы не имели дело с самим диапазоном, и я бы выдал обобщенное исключение ArgumentException, в котором указаны действительные значения, и я также задокументировал бы их в комментариях метода.

В зависимости от фактического значения и какое исключение подходит лучше всего:

• ArgumentException (что-то не так со значением)

• ArgumentNullException (аргумент нулевой, хотя это недопустимо)

• ArgumentOutOfRangeException (аргумент имеет значение за пределами допустимого диапазона)

Если это не достаточно точно, просто выведите свой собственный класс исключений из ArgumentException .

Ответ Yoooder меня просветил. Вход является недопустимым , если он недействителен в любое время, тогда как вход является неожиданным , если он недопустим для текущего состояния системы.

исключение аргумента.

• System.ArgumentException
• System.ArgumentNullException
• System.ArgumentOutOfRangeException

ArgumentException :

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

Несколько подклассов также существуют для определенных типов инвалидности. Ссылка содержит резюме подтипов и когда они должны применяться.

Краткий ответ:
Ни

Более длинный ответ:
с использованием аргумента * Exception (за исключением библиотеки, которая является Продукт на его, например, компонент библиотеки) является запахом. Исключения предназначены для обработки исключительных ситуаций, а не ошибок и не недостатков пользователя (т. Е. Пользователя API).

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

• утверждения не нужно проверять, пока бросай утверждения делай, а тестируй против ArgumentNullException выглядит смешно (попробуйте)
• Утверждения лучше сообщают о предполагаемом использовании устройства и являются ближе к тому, чтобы быть исполняемым документация, чем поведение класса Технические характеристики.
• Вы можете изменить поведение нарушения утверждения. Например, в отладочной компиляции окно сообщения в порядке, так что ваш QA сразу же поразит вас (вы также получите разрыв IDE на линии, где это происходит), в то время как в модульном тесте вы можете указать сбой утверждения как тестовый сбой

Вот как выглядит обработка пустых исключений (с сарказмом, очевидно):

try {
    library.Method(null);
}
catch (ArgumentNullException e) {
    // retry with real argument this time
    library.Method(realArgument);
}

Исключения следует использовать, когда ситуация ожидаемая, но исключительная (случаются вещи, которые находятся вне контроля потребителя, такие как сбой ввода-вывода). Аргумент * Исключение является признаком ошибки и должно (на мой взгляд) обрабатываться с помощью тестов и помогать с Debug.Assert

Кстати: в этом конкретном случае вы могли бы использовать тип Month вместо int. C # терпит неудачу, когда дело доходит до безопасности типов (Aspect # rulez!), Но иногда вы можете предотвратить (или отловить во время компиляции) эти ошибки все вместе.

И да, MicroSoft ошибается в этом.

Существует стандартное ArgumentException, которое вы можете использовать, или вы можете создать подкласс и создать свой собственный. Существует несколько определенных классов ArgumentException:

http://msdn.microsoft.com/en-us/library/system.argumentexception (VS.71) .aspx

Какой из них работает лучше всего