Casting ints to enums in C#

Question

There is something that I cannot understand in C#. You can cast an out-of-range int into an enum and the compiler does not flinch. Imagine this enum:

enum Colour
{
    Red = 1,
    Green = 2,
    Blue = 3
}

Now, if you write:

Colour eco;
eco = (Colour)17;

The compiler thinks that’s fine. And the runtime, too. Uh?

Why did the C# team decide to make this possible? This decision misses the point of using enums, I think, in scenarios like this:

void DoSomethingWithColour(Colour eco)
{
    //do something to eco.
}

In a strong-typed language like C#, I would like to assume that eco will always hold a legal Colour value. But this is not the case. A programmer could call my method with a value of 17 assigned to eco (as in previous code snippet), so the code in my method must not assume that eco holds a legal Colour value. I need to test for it explicitly and handle the exceptional values as I please. Why is this?

In my humble opinion, it would be much nicer if the compiler issued an error (or even a warning) message when casting an out-of range int into an enum, if the int value is known at compile time. If not, the runtime should throw an exception at the assignment statement.

What do you think? Is there any reason why this is so?

(Note. This is a question I posted ages ago on my blog but got no informative response.)

Answer 1

Guessing about 'why' is always dangerous, but consider this:

enum Direction { North =1, East = 2, South = 4, West = 8 }
Direction ne = Direction.North | Direction.East;

int value = (int) ne; // value == 3
string text = ne.ToString();  // text == "3"

When the [Flags] attribute is put in front of the enum, that last line changes to

string text = ne.ToString();  // text == "North, East"

Answer 2

Not sure about why, but I recently found this "feature" incredibly useful. I wrote something like this the other day

// a simple enum
public enum TransmissionStatus
{
    Success = 0,
    Failure = 1,
    Error = 2,
}
// a consumer of enum
public class MyClass 
{
    public void ProcessTransmissionStatus (TransmissionStatus status)
    {
        ...
        // an exhaustive switch statement, but only if
        // enum remains the same
        switch (status)
        {
            case TransmissionStatus.Success: ... break;
            case TransmissionStatus.Failure: ... break;
            case TransmissionStatus.Error: ... break;
            // should never be called, unless enum is 
            // extended - which is entirely possible!
            // remember, code defensively! future proof!
            default:
                throw new NotSupportedException ();
                break;
        }
        ...
    }
}

question is, how do I test that last case clause? It is completely reasonable to assume someone may extend TransmissionStatus and not update its consumers, like poor little MyClass above. Yet, I would still like to verify its behaviour in this scenario. One way is to use casting, such as

[Test]
[ExpectedException (typeof (NotSupportedException))]
public void Test_ProcessTransmissionStatus_ExtendedEnum ()
{
    MyClass myClass = new MyClass ();
    myClass.ProcessTransmissionStatus ((TransmissionStatus)(10));
}

Answer 3

I certainly see Cesar's point, and I remember this initially confused me too. In my opinion enums, in their current implementation, are indeed a little too low level and leaky. It seems to me that there would be two solutions to the problem.

1) Only allow arbitrary values to be stored in an enum if its definition had the FlagsAttribute. This way, we can continue to use them for a bitmask when appropriate (and explicitly declared), but when used simply as placeholders for constants we would get the value checked at runtime.

2) Introduce a separate primitive type called say, bitmask, that would allow for any ulong value. Again, we restrict standard enums to declared values only. This would have the added benefit of allowing the compiler to assign the bit values for you. So this:

[Flags]
enum MyBitmask
{ 
    FirstValue = 1, SecondValue = 2, ThirdValue = 4, FourthValue = 8 
}

would be equivalent to this:

bitmask MyBitmask
{
    FirstValue, SecondValue, ThirdValue, FourthValue 
}

After all, the values for any bitmask are completely predictable, right? As a programmer, I am more than happy to have this detail abstracted away.

Still, too late now, I guess we're stuck with the current implementation forever. :/

Answer 4

You don't need to deal with exceptions. The precondition for the method is that callers should use the enum, not cast any willy nilly int to the said enum. That would be madness. Isn't the point of enums not to use the ints?

Any dev who would cast 17 to the Colour enum would need 17 kicks up their backside as far as I'm concerned.

Answer 5

That is one of the many reasons why you should never be assigning integer values to your enums. If they have important values that need to be used in other parts of the code turn the enum into an object.

Answer 6

That is unexpected... what we really want is to control the casting... for instance:

Colour eco;
if(Enum.TryParse("17", out eco)) //Parse successfully??
{
  var isValid = Enum.GetValues(typeof (Colour)).Cast<Colour>().Contains(eco);
  if(isValid)
  {
     //It is really a valid Enum Colour. Here is safe!
  }
}

Answer 7

When you define an enum you are essentially giving names to values (syntatic sugar if you will). When you cast 17 to Colour, you are storing a value for a Colour that has no name. As you probably know in the end it is just an int field anyways.

This is akin to declaring an integer that would accept only values from 1 to 100; the only language I ever saw that supported this level of checking was CHILL.

Answer 8

if (!Enum.IsDefined(typeof(Colour), 17))
{
    // Do something
}

Answer 9

Short version:

Don't do this.

Trying to change enums into ints with only allowing valid values (maybe a default fallback) requires helper methods. At that point you have don't have an enum--you reallly have a class.

Doubly so if the ints are improtant--like Bryan Rowe said.

Answer 10

Old question, but this confused me recently, and Google brought me here. I found an article with further searching that finally made it click for me, and thought I'd come back and share.

The gist is that Enum is a struct, which means it's a value type (source). But in essence it acts as a derived type of the underlying type (int, byte, long, etc.). So if you can think of an Enum type as really just the same thing as its underlying type with some added functionality/syntactic sugar (as Otávio said) then you'll be aware of this "problem" and be able to protect against it.

Speaking of that, here is the heart of an extension method I wrote to easily convert/parse things to an Enum:

if (value != null)
{
    TEnum result;
    if (Enum.TryParse(value.ToString(), true, out result))
    {
        // since an out-of-range int can be cast to TEnum, double-check that result is valid
        if (Enum.IsDefined(typeof(TEnum), result.ToString()))
        {
            return result;
        }
    }
}

// deal with null and defaults...

The variable value there is of type object, as this extension has "overloads" that accept int, int?, string, Enum, and Enum?. They're all boxed and sent to the private method that does the parsing. By using both TryParse and IsDefined in that order, I can parse all the types just mentioned, including mixed case strings, and it's pretty robust.

Usage is like so (assumes NUnit):

[Test]
public void MultipleInputTypeSample()
{
    int source;
    SampleEnum result;

    // valid int value
    source = 0;
    result = source.ParseToEnum<SampleEnum>();
    Assert.That(result, Is.EqualTo(SampleEnum.Value1));

    // out of range int value
    source = 15;
    Assert.Throws<ArgumentException>(() => source.ParseToEnum<SampleEnum>());

    // out of range int with default provided
    source = 30;
    result = source.ParseToEnum<SampleEnum>(SampleEnum.Value2);
    Assert.That(result, Is.EqualTo(SampleEnum.Value2));
}

private enum SampleEnum
{
    Value1,
    Value2
}

Hope that helps somebody.

Disclaimer: we do not use flags/bitmask enums... this has not been tested with that usage scenario and probably wouldn't work.

Answer 11

Thought I'd share the code I ended up using to validate Enums, as so far we don't seem to have anything here that works...

public static class EnumHelper<T>
{
    public static bool IsValidValue(int value)
    {
        try
        {
            Parse(value.ToString());
        }
        catch
        {
            return false;
        }

        return true;
    }

    public static T Parse(string value)
    {
        var values = GetValues();
        int valueAsInt;
        var isInteger = Int32.TryParse(value, out valueAsInt);
        if(!values.Select(v => v.ToString()).Contains(value)
            && (!isInteger || !values.Select(v => Convert.ToInt32(v)).Contains(valueAsInt)))
        {
            throw new ArgumentException("Value '" + value + "' is not a valid value for " + typeof(T));
        }

        return (T)Enum.Parse(typeof(T), value);
    }

    public static bool TryParse(string value, out T p)
    {
        try
        {
            p = Parse(value);
            return true;
        }
        catch (Exception)
        {
            p = default(T);
            return false;
        }

    }

    public static IEnumerable<T> GetValues()
    {
        return Enum.GetValues(typeof (T)).Cast<T>();
    }
}

Answer 12

It would throw an error by using the Enum.Parse();

Enum parsedColour = (Colour)Enum.Parse(typeof(Colour), "17");

Might be worth using to get a runtime error thrown, if you like.