Лучшее исключение для недопустимого общего аргумента типа

Я бы избегал NotSupportedException. Это исключение используется в среде, где метод не реализован и есть свойство, указывающее, что этот тип операции не поддерживается. Здесь это не подходит

• Бесстыдный себя Ссылка: http://blogs.msdn.com/jaredpar/archive/2008/12/12/notimplementedexception-vs-notsupportedexception.aspx

Я думаю, что InvalidOperationException - это наиболее подходящее исключение, которое вы могли бы здесь создать.

Generic programming should not throw at runtime for invalid type parameters. It should not compile, you should have a compile time enforcement. I don't know what IsFlag() contains, but perhaps you can turn this into a compile time enforcement, like trying to create a type that is only possible to create with 'flags'. Perhaps a traits class can help.

Update

If you must throw, I'd vote for InvalidOperationException. The reasoning is that generic types have parameters and errors related to (method) parameters are centered around the ArgumentException hierarchy. However, the recommendation on ArgumentException states that

if the failure does not involve the arguments themselves, then InvalidOperationException should be used.

There is at least one leap of faith in there, that method parameters recommendations are also to be applied to generic parameters, but there isn't anything better in the SystemException hierachy imho.

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

Я бы выбрал NotSupportedException . Хотя ArgumentException выглядит нормально, это действительно ожидаемо, когда аргумент, переданный методу, неприемлем. Аргумент типа - это определяющая характеристика фактического метода, который вы хотите вызвать, а не реальный «аргумент». InvalidOperationException следует генерировать, если выполняемая вами операция может быть допустимой в некоторых случаях, но для конкретной ситуации это неприемлемо.

NotSupportedException генерируется, когда операция изначально не поддерживается. Например, при реализации интерфейса, в котором конкретный член не имеет смысла для класса. Это похоже на аналогичную ситуацию.

Выбрасывание настраиваемого исключения всегда должно выполняться в любом случае, когда это вызывает сомнения. Пользовательское исключение будет работать всегда, независимо от потребностей пользователей API. Разработчик может поймать любой тип исключения, если ему все равно, но если разработчику требуется особая обработка, он будет SOL.

Идентификатор NotSupportedExpcetion.

Как насчет наследования от NotSupportedException. Хотя я согласен с @Mehrdad в том, что это имеет наибольший смысл, я слышал вашу точку зрения, что это, похоже, не идеально подходит. Поэтому наследуйте от NotSupportedException, и таким образом люди, кодирующие ваш API, все равно могут перехватить NotSupportedException.

Я бы тоже проголосовал для InvalidOperationException. Я сделал (неполную) блок-схему рекомендаций по выбрасыванию исключений .NET на основе рекомендаций по проектированию фреймворка, 2-е изд. некоторое время назад, если кому-то интересно.

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

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

Если пользователь пытался передать что-то, что не было перечислением, я бы выбрасывал InvalidOperationException.

Изменить:

Остальные поднимают интересный вопрос, что это не поддерживается. Меня беспокоит только NotSupportedException, что обычно это исключения, которые возникают, когда в систему вводится «темная материя», или, другими словами, «Этот метод должен войти в систему через этот интерфейс, но мы выиграли не включайте его до версии 2.4 »

Я также видел, как NotSupportedExceptions генерировался как исключение лицензирования« вы используете бесплатную версию этого программного обеспечения, эта функция не поддерживается ».

Редактировать 2:

Другой возможный: