无效泛型类型参数的最佳例外 [英] Best exception for an invalid generic type argument

问题描述

我正在为 UnconstrainedMelody 编写一些代码，该代码具有通用的方法使用枚举。

现在，我有一个静态类，其中包含一些仅用于标志枚举的 方法。我不能将其添加为约束，所以它们也可能被其他枚举类型调用。在这种情况下，我想抛出一个异常，但我不知道要抛出什么。

只是为了让这个具体，如果我有这样的东西：

  //返回一个值，其中所有位都由任何值设置
 public static T GetBitMask< T>（）其中T：struct，IEnumConstraint 
 {
 if（！IsFlags< T>（））//此方法不抛出
 {
 throw new？ 
} 
 //正常工作
} 
  

抛出最好的例外 ArgumentException 听起来是逻辑的，但它是一个类型参数，而不是一个正常的参数，这很容易混淆事物。我应该介绍我自己的 TypeArgumentException 类吗？使用 InvalidOperationException ？ NotSupportedException异常？还有其他什么？

我会而是不会为此创建自己的例外，除非它显然是正确的事情。

解决方案

NotSupportedException 听起来很明显，但文档明确指出，它应该用于不同的目的。从MSDN类的注释：

在基类中有不支持
的方法，
期望这些方法将在派生类
中实现
。派生类可能
仅从基类实现一个方法
的子集，并为
不支持的方法抛出
NotSupportedException。

当然，有一种方法，其中 NotSupportedException 显然是足够好的，特别是考虑到它的常识意义。话虽如此，我不知道是否正确。

鉴于无约束旋律 ...

有各种有用的东西可以可以使用通用的
方法/类，其中有一个类型约束为T：enum或T：
delegate - 但不幸的是，这些在C＃中被禁止。

此实用程序库围绕着使用ildasm / ilasm ...的禁止工作。

...似乎/ code>可能是有序的，尽管我们在创建自定义异常之前我们必须满足的高度的举证责任。像 InvalidTypeParameterException 可能在整个库中都有用（或者也许不是 - 这肯定是一个边缘案例，对吗？）

客户需要能够区别于BCL异常？客户可能会意外地使用香草（）枚举您如何回答在编写自定义异常类时应考虑什么因素？

I'm currently writing some code for UnconstrainedMelody which has generic methods to do with enums.

Now, I have a static class with a bunch of methods which are only meant to be used with "flags" enums. I can't add this as a constraint... so it's possible that they'll be called with other enum types too. In that case I'd like to throw an exception, but I'm not sure which one to throw.

Just to make this concrete, if I have something like this:

// Returns a value with all bits set by any values
public static T GetBitMask<T>() where T : struct, IEnumConstraint
{
    if (!IsFlags<T>()) // This method doesn't throw
    {
        throw new ???
    }
    // Normal work here
}

What's the best exception to throw? ArgumentException sounds logical, but it's a type argument rather than a normal argument, which could easily confuse things. Should I introduce my own TypeArgumentException class? Use InvalidOperationException? NotSupportedException? Anything else?

I'd rather not create my own exception for this unless it's clearly the right thing to do.

解决方案

NotSupportedException sounds like it plainly fits, but the documentation clearly states that it should be used for a different purpose. From the MSDN class remarks:

There are methods that are not supported in the base class, with the expectation that these methods will be implemented in the derived classes instead. The derived class might implement only a subset of the methods from the base class, and throw NotSupportedException for the unsupported methods.

Of course, there's a way in which NotSupportedException is obviously good enough, especially given its common-sense meaning. Having said that, I'm not sure if it's just right.

Given the purpose of Unconstrained Melody ...

There are various useful things that can be done with generic methods/classes where there's a type constraint of "T : enum" or "T : delegate" - but unfortunately, those are prohibited in C#.

This utility library works around the prohibitions using ildasm/ilasm ...

... it seems like a new Exception might be in order despite the high burden of proof we justly have to meet before creating custom Exceptions. Something like InvalidTypeParameterException might be useful throughout the library (or maybe not - this is surely an edge case, right?).

Will clients need to be able to distinguish this from BCL Exceptions? When might a client accidentally call this using a vanilla enum? How would you answer the questions posed by the accepted answer to What factors should be taken into consideration when writing a custom exception class?

这篇关于无效泛型类型参数的最佳例外的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！