处理枚举时不带默认值的 Switch 语句

Question

自从我开始使用 .NET 以来，这一直是我的一个烦恼，但我很好奇，以防我遗漏了一些东西。 我的代码片段不会编译（请原谅示例的强制性质），因为（根据编译器）缺少返回语句：

public enum Decision { Yes, No}

    public class Test
    {
        public string GetDecision(Decision decision)
        {
            switch (decision)
            {
                case Decision.Yes:
                    return "Yes, that's my decision";
                case Decision.No:
                    return "No, that's my decision";

            }
        }
    }

现在我知道我可以简单地放置一个默认语句来摆脱编译器警告，但要我的脑海中不仅有那些多余的代码，还有危险的代码。 如果枚举位于另一个文件中，并且另一个开发人员出现并将Maybe添加到我的枚举中，它将由我的默认子句处理，该默认子句对Maybe一无所知，并且确实有一个我们很有可能引入逻辑错误。

然而，如果编译器允许我使用上面的代码，它就会识别出我们有问题，因为我的 case 语句将不再涵盖枚举中的所有值。 当然对我来说听起来更安全。

这对我来说是根本错误的，我想知道这是否只是我遗漏的东西，或者我们在 switch 语句中使用枚举时是否必须非常小心？

编辑： 我知道我可以在默认情况下引发异常或在开关之外添加返回，但这仍然是从根本上解决不应该是错误的编译器错误的黑客行为。

关于枚举实际上只是一个 int，这是 .NET 肮脏的小秘密之一，这确实非常令人尴尬。 让我声明一个具有有限数量可能性的枚举，并给我一个编译：

Decision fred = (Decision)123;

然后如果有人尝试以下操作，则抛出异常：

int foo = 123;
Decision fred = (Decision)foo;

编辑2：

一些人对当发生的情况发表了评论枚举位于不同的程序集中，这将如何导致问题。 我的观点是，这是我认为应该发生的行为。 如果我更改方法签名，这将导致问题，我的前提是更改枚举应该是相同的。 我的印象是很多人认为我不了解 .NET 中的枚举。 我确实认为这种行为是错误的，我希望有人可能知道一些非常晦涩的功能，这些功能会改变我对 .NET 枚举的看法。

Answer 1

哎呀，情况比仅仅处理枚举要糟糕得多。 我们甚至不为布尔值这样做！

public class Test {        
  public string GetDecision(bool decision) {
    switch (decision) {
       case true: return "Yes, that's my decision";                
       case false: return "No, that's my decision"; 
    }
  }
}

产生相同的错误。

即使您解决了枚举能够接受任何值的所有问题，您仍然会遇到这个问题。 该语言的流分析规则根本不认为没有默认值的开关是所有可能的代码路径的“详尽”，即使你和我都知道它们是这样的。

我非常想解决这个问题，但坦率地说，我们有比解决这个愚蠢的小问题更重要的优先事项，所以我们从来没有抽出时间来解决它。

---

更新：低性价比的功能本身并不能证明其努力的合理性，有时当另一种语言功能需要它时就会完成，这就是这里发生的情况。 C# 需要对改进的模式匹配和 switch 表达式进行详尽检查。 规则是：

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specation/patterns#114-pattern-exhaustiveness

Answer 2

在 default 子句中抛出异常：

default:
    throw new ArgumentOutOfRangeException("decision");

这可以确保覆盖所有可能的路径，同时避免因添加新值而导致的逻辑错误。

Answer 3

这是因为 decision 的值实际上可能是不属于枚举的值，例如：

string s = GetDecision((Decision)42);

编译器或 CLR 不会阻止这种情况。 该值也可以是枚举值的组合：（

string s = GetDecision(Decision.Yes | Decision.No);

即使枚举没有 Flags 属性）

因此，您应该始终放置一个 切换时的默认情况，因为您无法显式检查所有可能的值

Answer 4

public enum Decision { Yes, No}

public class Test
{
    public string GetDecision(Decision decision)
    {
        switch (decision)
        {
            case Decision.Yes:
                return "Yes, that's my decision";
            case Decision.No:
                return "No, that's my decision";
            default: throw new Exception(); // raise exception here.

        }
    }
}

Answer 5

默认设置是为了保护您。 抛出一个默认的异常，如果有人添加了一个额外的枚举，你就会被一些东西来标记它。

Answer 6

我意识到这是一个线程复活...

我个人认为 switch 的工作方式是正确的，并且它按照我逻辑上想要的方式运行。

我很惊讶听到对默认标签的如此抱怨。

如果您只有一组严格的枚举或要测试的值，则不需要所有异常处理行或开关外部的返回等。

只需将默认标签放在其他标签之一上即可，也许这个标签是最常见的反应。 在您的示例中，哪一个可能并不重要。 简短、甜蜜，它满足了您消除编译器警告的需求：

switch (decision)
{
    default:
    case Decision.Yes:
        return "Yes, that's my decision";
    case Decision.No:
        return "No, that's my decision";
}

如果您不希望默认为“是”，请将默认标签放在“否”标签上方。

Answer 7

为了分享一个奇怪的想法，如果没有别的，这里是：

你总是可以实现你自己的强枚举

......并且自从引入 nameof 运算符后，你也可以在 switch-cases 中使用它们。
（并不是说您以前在技术上无法这样做，而是很难使此类代码可读且重构友好。）

public struct MyEnum : IEquatable<MyEnum>
{
    private readonly string name;
    private MyEnum(string name) { name = name; }

    public string Name
    {
        // ensure observable pureness and true valuetype behavior of our enum
        get { return name ?? nameof(Bork); } // <- by choosing a default here.
    }

    // our enum values:
    public static readonly MyEnum Bork;
    public static readonly MyEnum Foo;
    public static readonly MyEnum Bar;
    public static readonly MyEnum Bas;

    // automatic initialization:
    static MyEnum()
    {
        FieldInfo[] values = typeof(MyEnum).GetFields(BindingFlags.Static | BindingFlags.Public);
        foreach (var value in values)
            value.SetValue(null, new MyEnum(value.Name));
    }

    /* don't forget these: */
    public override bool Equals(object obj)
    {
        return obj is MyEnum && Equals((MyEnum)obj);
    }
    public override int GetHashCode()
    {
        return Name.GetHashCode();
    }
    public override string ToString()
    {
        return Name.ToString();
    }
    public bool Equals(MyEnum other)
    {
        return Name.Equals(other.Name);
    }
    public static bool operator ==(MyEnum left, MyEnum right)
    {
        return left.Equals(right);
    }
    public static bool operator !=(MyEnum left, MyEnum right)
    {
        return !left.Equals(right);
    }
}

并如此使用它：

public int Example(MyEnum value)
{
    switch(value.Name)
    {
        default: //case nameof(MyEnum.Bork):
            return 0;
        case nameof(MyEnum.Foo):
            return 1;
        case nameof(MyEnum.Bar):
            return 2;
        case nameof(MyEnum.Bas):
            return 3;
    }
}

您当然会像这样调用该方法：
int test = 示例(MyEnum.Bar); // returns 2

我们现在可以轻松获得 Name 基本上只是一个额外的好处，是的，一些读者可能会指出，这基本上是一个没有 null 情况的 Java 枚举（因为这不是一个类）。 就像在 Java 中一样，您可以添加任何您想要的额外数据和/或属性，例如序数值。

可读性：检查！
智能感知：检查！
可重构性：检查！
是 ValueType：检查！
真实枚举：检查！
...
性能好吗？ 与原生枚举相比； 没有。
你应该使用这个吗？ 嗯......

拥有真正的枚举对您来说有多重要，这样您就可以摆脱枚举运行时检查及其伴随的异常？
我不知道。 亲爱的读者，我无法真正回答这个问题； 给每个人自己的。

...实际上，当我写这篇文章时，我意识到让结构“包装”一个普通的枚举可能会更干净。 （静态结构体字段和相应的普通枚举在与上面类似的反射的帮助下相互镜像。）只要永远不要使用普通枚举作为参数就可以了。

更新：

是的，花了一整夜测试我的想法，我是对的：我现在在 C# 中拥有近乎完美的 Java 风格枚举。 使用干净并且性能得到提高。
最重要的是：所有讨厌的东西都封装在基类中，您自己的具体实现可以像这样干净：

// example java-style enum:
public sealed class Example : Enumeration<Example, Example.Const>, IEnumerationMarker
{
    private Example () {}

    /// <summary> Declare your enum constants here - and document them. </summary>
    public static readonly Example Foo = new Example ();
    public static readonly Example Bar = new Example ();
    public static readonly Example Bas = new Example ();

    // mirror your declaration here:
    public enum Const
    {
        Foo,
        Bar,
        Bas,
    }
}

这就是您可以做的：

• 您可以添加您想要的任何私有字段。
• 您可以添加任何您想要的公共非静态字段。
• 您可以添加任何您想要的属性和方法。
• 您可以按照自己的意愿设计构造函数，因为：
• 您可以忘记基本构造函数的麻烦。 基本构造函数是无参数的！

这是您必须做的：

1. 您的枚举必须是密封类。
2. 所有的构造函数都必须是私有的。
3. 您的枚举必须直接继承自 Enumeration并继承空的 IEnumerationMarker 接口。
4. Enumeration的第一个泛型类型参数是 必须是你的枚举类。
5. 对于每个公共静态字段，System.Enum 中必须存在一个名称相同的值（您指定为 Enumeration的第二个泛型类型参数）。
6. 所有公共静态字段都必须是只读的并且属于枚举类型。
7. 在类型初始化期间，必须为所有公共静态字段分配唯一的非空值。

目前，上述每个不变量都在类型初始化时断言。 稍后可能会尝试调整它，看看是否可以在编译时检测到其中的一些内容。

要求理由：

1. 您的枚举必须是密封的，因为如果不是密封的，那么其他不变量会变得更加复杂，并且没有明显的好处。
2. 允许公共构造函数是没有意义的。 它是一种枚举类型，基本上是一种单例类型，但具有一组固定的实例，而不是只有一个。
3. 原因与第一个相同。 如果不是这样，反射和其他一些不变性和约束检查就会变得混乱。
4. 我们需要这个泛型类型参数，以便类型系统可以用于通过高性能编译/Jit 时间绑定来唯一存储我们的枚举数据。 不使用哈希表或其他慢速机制！ 理论上它可以被删除，但我认为这样做不值得增加复杂性和性能成本。
5. 这一点应该是很明显的。 我们需要这些常量来制作优雅的 switch 语句。 当然，我可以创建第二个没有它们的枚举类型； 您仍然可以使用前面显示的 nameof 方法进行切换。 它只是性能不那么好。 我还在考虑是否应该放宽这个要求。 我将对此进行实验...
6. 由于显而易见的原因，您的枚举常量必须是公共和静态的，并且只读字段，因为a）具有只读枚举实例意味着所有相等检查都简化为引用相等； b) 属性更加灵活和冗长，坦率地说，这对于枚举实现来说都是不受欢迎的属性。 最后，所有公共静态字段都必须是枚举类型，因为； a）它使您的枚举类型更干净，更少混乱； b) 使反射更简单； c) 无论如何你都可以自由地对属性做任何事情，所以这是一个非常软的限制。
7. 这是因为我正在努力将“讨厌的反射魔法”保持在最低限度。 我不希望我的枚举实现需要完全信任执行。 这将严重限制它的实用性。 更准确地说，调用私有构造函数或写入只读字段可能会在低信任环境中引发安全异常。 因此，您的枚举必须在初始化时实例化您的枚举常量 - 然后我们可以“干净地”填充这些实例的（内部）基类数据。

无论如何，如何使用这些 java 风格的枚举？

我现在实现了这些东西：

int ordinal = Example.Bar.Ordinal; // will be in range: [0, Count-1]
string name = Example.Bas.Name; // "Bas"
int count = Enumeration.Count<Example>(); // 3
var value = Example.Foo.Value; // <-- Example.Const.Foo

Example[] values;
Enumeration.Values(out values);

foreach (var value in Enumeration.Values<Example>())
    Console.WriteLine(value); // "Foo", "Bar", "Bas"

public int Switching(Example value)
{
    if (value == null)
        return -1;

    // since we are switching on a System.Enum tabbing to autocomplete all cases works!
    switch (value.Value)
    {
        case Example.Const.Foo:
            return 12345;
        case Example.Const.Bar:
            return value.GetHasCode();
        case Example.Const.Bas:
            return value.Ordinal * 42;
        default:
            return 0;
    }
}

抽象 Enumeration 类还将为我们实现 IEquatable 接口，包括适用于 Example 实例的 == 和 != 运算符。

除了类型初始化期间所需的反射之外，一切都是干净且高性能的。 可能会继续实现 java 的枚举专用集合。

那么这段代码在哪里？

我想看看在发布之前是否可以对其进行更多清理，但到本周末它可能会出现在 GitHub 上的开发分支上- 除非我找到其他疯狂的项目可以做！ ^_^

现在在 GitHub
请参阅 Enumeration.cs 和 Enumeration_T2.cs。
它们目前是我正在开发的一个非常多的 wip 库的开发分支的一部分。
（还没有什么是“可发布的”，并且随时可能发生重大更改。）
...现在，库的其余部分主要是一堆样板文件，用于将所有数组方法扩展到多列数组，使多列数组可与 Linq 一起使用，以及用于公开（私有）的高性能 ReadOnlyArray 包装器（不可变结构）以安全的方式存储数组，而无需始终创建副本。

除了最新的开发提交之外，所有内容*都完全记录在案，并且 IntelliSense 友好。
（*java 枚举类型仍然是 wip，一旦我完成了它们的设计，就会正确记录它们。）

Answer 8

我总是认为这种默认是失败/例外。

所以这里不会是“也许”，而是“无效决定，请联系支持人员”。

我不知道它会如何发展，但这将是包罗万象/例外的情况。

Answer 9

除了这种情况之外，您还可以将任何 int 转换为您的枚举，并拥有一个您不处理的枚举。 还有一种情况是，如果枚举位于外部 .dll 中，并且该 .dll 已更新，则向枚举添加其他选项（如“是”、“否”、“也许”）也不会破坏您的代码。 因此，为了处理这些未来的更改，您还需要默认情况。 无法保证在编译时您知道枚举在其生命周期中具有的每个值。

Answer 10

不要抱怨 switch 语句的工作原理，而是通过在枚举上使用扩展方法来完全避免它，如所述 此处和此处。

这种方法的好处是，在添加新的枚举值时，您不会遇到忘记更新 GetDecision switch 语句的情况，因为它们都在同一个位置 - 在枚举声明中。

我不知道这种方法的效率，实际上，目前甚至没有考虑。 是的，我只是不在乎，因为这对我来说太容易了，我想，“去他妈的电脑吧，这就是它的作用——努力工作。” （当天网接管时，我可能会后悔这种态度。）

如果我需要从其中一个属性值返回到枚举值，我可以简单地构建一个反向字典并用一行代码填充它。

（我通常将“未设置”作为第一个枚举元素，因为正如OP所指出的，C#枚举实际上是一个int，所以未初始化的变量将为零或第一个枚举值）

public enum Decision
{
  [DisplayText("Not Set")]
  NotSet,
  [DisplayText("Yes, that's my decision")]
  Yes,
  [DisplayText("No, that's my decision")]
  No
}

public static class XtensionMethods
{
  public static string ToDisplayText(this Enum Value)
  {
    try
    {
      Type type = Value.GetType();
      MemberInfo[] memInfo =
        type.GetMember(Value.ToString());

      if (memInfo != null && memInfo.Length > 0)
      {
        object[] attrs = memInfo[0]
          .GetCustomAttributes(typeof(DisplayText), false);
        if (attrs != null && attrs.Length > 0)
          return ((DisplayText)attrs[0]).DisplayedText;
      }
    }
    catch (Exception ex)
    {
      throw new Exception(
        "Error in XtensionMethods.ToDisplayText(Enum):\r\n" + ex.Message);
    }
    return Value.ToString();
  }

  [System.AttributeUsage(System.AttributeTargets.Field)]
  public class DisplayText : System.Attribute
  {
    public string DisplayedText;

    public DisplayText(string displayText)
    {
      DisplayedText = displayText;
    }
  }
}

使用内联，例如：

myEnum.ToDisplayText();

或者包装在函数中，如果您愿意的话：

public string GetDecision(Decision decision)
{
  return decision.ToDisplayText();
}