Have you been burned by versioning enums
Kit George is working on a guideline
around versioning wrt Enums and he needs your feedback. "urn:schemas-microsoft-com:office:office" />
It’s a know issue that adding values
to enums is bad (from a breaking change perspective), WHEN someone is
exhaustively switching over that enum. For example:
I have an enum, with three elements
in it, and I have some API, which I have written to return a
Color:
public enum
Color { Red , Green, Blue };
public
class Service
{
public static
Color
GetColor() {
// returns a valid Color
}
}
Someone consumes this enum by
writing this (broken) code:
Color c = Service.GetColor();
switch (c) {
case Color.Green :
Console.WriteLine(“taking
some action based on Green”);
break;
case Color.Blue :
Console.WriteLine(“taking
some action based on Blue”);
break;
default : // Just
assume Red is the only other value
Console.WriteLine(“taking
some action based on Red”);
break;
}
The issue is: what happens when I
want to add more colors to my enum? For example, I want to change Color, so that
now, it has this definition:
public
enum Color {
Red , Green,
Blue, Yellow,
Purple };
Questions
- Have you, or your team ever hit
this problem with a managed API being updated in this way (an element added to
an enum), and affecting your code? - Same question, but for an
unmanaged API? - If you weren’t aware of this issue
previously, do you think it might affect your code in the future? - What if we simply allow this kind
of change: do you think it’s that bad?