Brad Abrams queries, in a post, about versioned enums and a particular code construct that assumes a constant set of enums. The example is:
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;
}
I, of course, recommend never writing such code in production applications. My perspective has always been one of fail fast:
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;
case Color.Red :
Console.WriteLine(“taking some action based on Red”);
break;
default : // Allways check that you know what you got.
throw new InternalApplicationException(
“Unknown color: '“ + color.ToString() + “');
break;
}
That way your application will not fail in an unexpected way. This may not, of course, make it robust in the face of change. However, few people have the luxury to version proof all their code. You would only do that for Color if you expected it to change in the future. Otherwise the above approach is the preferred.
For those of you who haven't followed the discussion on my
previous post,
Don Box was kind enough to answer what questions remained from his interview with Mary Jo Foley.
Check it out.