枚举方法参数的例外情况 [英] Exceptions for Enum Method Parameters

问题描述

在带有 enum 作为参数的类方法中，是否有必要捕获超出范围事件的参数？



例如 InvalidEnumArgumentException 或 ArgumentOutOfRangeException ？

Could it ever be necessary, in a class method with an enum as a parameter, to catch an argument out of range event?

Such as InvalidEnumArgumentException or ArgumentOutOfRangeException?

public virtual void ToGrey(RGBGreyScaleMethod method)
{
    Switch (method) {
        case RGBGreyScaleMethod.Average:
            this.ByAverage();
	    break;
        case RGBGreyScaleMethod.BlueChannel:
	    this.FromBlue();
	    break;
        case RGBGreyScaleMethod.Brightness:
            this.FromBrightness();
            break;
        case RGBGreyScaleMethod.Decompose:
            this.Decompose();
            break;
        case RGBGreyScaleMethod.Desaturate:
            this.Desaturate();
            break;
        case RGBGreyScaleMethod.GreenChannel:
            this.FromGreen();
            break;
        case RGBGreyScaleMethod.RedChannel:
            this.FromRed();
            break;
        default:
            //ToDo: Clean this up and add XML comments
            //ToDo: Consider InvalidEnumArgumentException as alternative
            Throw new ArgumentOutOfRangeException("The supplied RGBGreyScaleMethod was not recognised");
    }
}

public enum RGBGreyScaleMethod
{
    Desaturate
    Decompose
    Brightness
    Average
    RedChannel
    GreenChannel
    BlueChannel
}

或者这样的想法会被编译器，运行时环境自动处理吗？即在这种情况下会发现错误是多余的吗？



谢谢，

M

Or would such a think be automagically handled by the compiler, run time environment? I.e. would catching the error in such a case be superfluous?

Thanks,
M

推荐答案

当然没有什么会抛出异常或以其他方式表示无效的枚举值，除非你自己做。



但是，你应该考虑一下：你呢？真的需要警惕这种情况吗？确实，这种情况会如何出现？例如，您可以开发一些计算某个整数值的代码，然后将其类型转换为枚举类型，以调用您的方法。当然，这是从有效集中获取值的风险。 决议？不要做恶（在这种情况下，从整数类型转换），你就不会有问题。



另一种情况是：值来自其他进程的流，通过网络。发送进程可能正在某些其他计算机上运行，​​您可以使用过时的或更新的库，这是一个定义了枚举类型的程序集。然后，如果枚举类型在网络应用程序的不同侧面上不同，则有效的枚举值集合中的值（对于一个边/版本）是非常可能的。 决议？不要马虎，你也不会有这个问题。怎么样？不适用于不兼容的版本。创建增量版本更新机制，检查所有程序集的所有版本（通过反射）并通过网络发送此版本信息以进行严格检查。



最后，将长期案例陈述与单独的枚举成员进行比较的整个想法并不是一个好主意。请参阅我的文章，解释一些更先进，更不细致且不易出错的技术：

枚举类型不枚举！解决.NET和语言限制 [ ^ ]，

动态方法调度程序 [ ^ ]。

-SA

Of course nothing would throw exception or otherwise indicate invalid enumeration value unless you do it by yourself.

However, you should think about it: do you really need a guard against such cases? Indeed, how such cases can appear? For example, you can develop some code which calculates some integer value, and then type-cast it to your enumeration type, to call your method. Naturally, this is the risk of getting the value out of the valid set. A resolution? Don't do evil (in this case, type cast from integer), and you won't have a problem.

Another case is: the values comes from the stream from some other process, via network. It is possible that the sending process is running on some other machine, where you use obsolete or newer library, an assembly where your enumeration type is defined. Then again, if the enumeration type is different on different sides of the network application, the value out of valid set of enumeration values (for one of the sides/version) is quite possible. A resolution? Don't be sloppy, and you won't have this problem. How? Don't work with incompatible version. Create a mechanism of incremental version update, a mechanism checking up all versions of all assemblies (through reflection) and sending this version information through network for rigorous check-up.

And finally, the whole idea of your long case statement comparing value with separate enumeration members is not a very good idea. Please see my articles explaining some more advanced and less meticulous and less error-prone techniques:
Enumeration Types do not Enumerate! Working around .NET and Language Limitations[^],
Dynamic Method Dispatcher[^].

—SA

不，它不会是自动的。

我的做法是在你的代码执行的同时在基于枚举的switch语句的默认情况下包含一个ArgumentException抛出 - 在编译时没有办法捕获缺失值，所以如果我添加和选项对于枚举，我需要一些方法来检测我忘记更新这个特定的开关，而不是我需要的。

我们的代码之间的唯一区别是我的异常包括无法识别的开关值，因此如果我记录它，我也会记录错过的值。



BL ** DY平板电脑自动纠正！[/ edit]

No, it wouldn't be automatic.
My practice is to include an ArgumentException throw on the default case of an enum based switch statement for the same time your code does - there is no way to catch a "missing value" at compile time, so if I add and option to the enum, I need some way to detect that I have forgotten to update this particular switch out of the however many I have needed.
The only difference between our codes is that my exception includes the unrecognised switch value so that if I log it, I log the missed value as well.

[edit]BL**DY tablet auto correct![/edit]

这篇关于枚举方法参数的例外情况的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！