Is it possible to bind a switch statement to an Enum such that a compile-time
error is raised if not all values within the Enum are handled in the switch
statement? I realise you can use default: to catch unhandled cases, but of
course this is only at run-time.

Example:
public enum MyEnum
{
one, two, three, four
}

....

MyEnum myVar;
switch (myVar)
{
case MyEnum.one:
break;
case MyEnum.two:
break;
case MyEnum.three:
break;
// I would like this to raise a compilation error as there is no case
for MyVar.four
}

Thanks, Adam

Adam Blair wrote:
> Is it possible to bind a switch statement to an Enum such that a compile-time
> error is raised if not all values within the Enum are handled in the switch
> statement? I realise you can use default: to catch unhandled cases, but of
> course this is only at run-time.
>
> Example:
> public enum MyEnum
> {
> one, two, three, four
> }
>
> ....
>
> MyEnum myVar;
> switch (myVar)
> {
> case MyEnum.one:
> break;
> case MyEnum.two:
> break;
> case MyEnum.three:
> break;
> // I would like this to raise a compilation error as there is no case

default:
System.Diagnostics.Debug.Assert(false, "unhandled enum value");
break;

> for MyVar.four
> }
>
> Thanks, Adam
>

That compiler option does not exist (or I must be unaware of it).
I suggest calling Debug.Assert(false) in the default clause. This way
you are notified of any unhandled values, that is, in the debug version
of your application. The release version will silently ignore the
assert statement. You could also throw an exception in the default
case, but this would also happen in the release version, which might not
be very appealing.
BTW, I added some code inline.

Cheers,

Benoit.

Thanks for your response. Your idea is useful, but unfortunately it still
relies on traversing all code paths (and developers to be watching the Output
window).

Adam

"Benoit Vreuninckx" wrote:

> Adam Blair wrote:
> > Is it possible to bind a switch statement to an Enum such that a compile-time
> > error is raised if not all values within the Enum are handled in the switch
> > statement? I realise you can use default: to catch unhandled cases, but of
> > course this is only at run-time.
> >
> > Example:
> > public enum MyEnum
> > {
> > one, two, three, four
> > }
> >
> > ....
> >
> > MyEnum myVar;
> > switch (myVar)
> > {
> > case MyEnum.one:
> > break;
> > case MyEnum.two:
> > break;
> > case MyEnum.three:
> > break;
> > // I would like this to raise a compilation error as there is no case
>
> default:
> System.Diagnostics.Debug.Assert(false, "unhandled enum value");
> break;
>
> > for MyVar.four
> > }
> >
> > Thanks, Adam
> >
>
> That compiler option does not exist (or I must be unaware of it).
> I suggest calling Debug.Assert(false) in the default clause. This way
> you are notified of any unhandled values, that is, in the debug version
> of your application. The release version will silently ignore the
> assert statement. You could also throw an exception in the default
> case, but this would also happen in the release version, which might not
> be very appealing.
> BTW, I added some code inline.
>
> Cheers,
>
> Benoit.
>

A compilation error doesn't make sense there since during compile time, the
value of myVar is not populated.
You do want a runtime error though, and Debug.Assert is a good suggestion
there. Debug.Assert will not require the developers to look at the output
window.

You could always throw an exception for a little bit more intrusive alert.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik



"Adam Blair" <Adam (E-Mail Removed)> wrote in message
news:4A5AC66A-2913-4156-9C03-(E-Mail Removed)...
> Is it possible to bind a switch statement to an Enum such that a
compile-time
> error is raised if not all values within the Enum are handled in the
switch
> statement? I realise you can use default: to catch unhandled cases, but of
> course this is only at run-time.
>
> Example:
> public enum MyEnum
> {
> one, two, three, four
> }
>
> ...
>
> MyEnum myVar;
> switch (myVar)
> {
> case MyEnum.one:
> break;
> case MyEnum.two:
> break;
> case MyEnum.three:
> break;
> // I would like this to raise a compilation error as there is no case
> for MyVar.four
> }
>
> Thanks, Adam
>

What i was after is an indication - at compilation - if there *could ever be*
a value of myVar that is not handled.

"Sahil Malik" wrote:

> A compilation error doesn't make sense there since during compile time, the
> value of myVar is not populated.
> You do want a runtime error though, and Debug.Assert is a good suggestion
> there. Debug.Assert will not require the developers to look at the output
> window.
>
> You could always throw an exception for a little bit more intrusive alert.
>
> - Sahil Malik
> http://dotnetjunkies.com/weblog/sahilmalik
>
>
>
> "Adam Blair" <Adam (E-Mail Removed)> wrote in message
> news:4A5AC66A-2913-4156-9C03-(E-Mail Removed)...
> > Is it possible to bind a switch statement to an Enum such that a
> compile-time
> > error is raised if not all values within the Enum are handled in the
> switch
> > statement? I realise you can use default: to catch unhandled cases, but of
> > course this is only at run-time.
> >
> > Example:
> > public enum MyEnum
> > {
> > one, two, three, four
> > }
> >
> > ...
> >
> > MyEnum myVar;
> > switch (myVar)
> > {
> > case MyEnum.one:
> > break;
> > case MyEnum.two:
> > break;
> > case MyEnum.three:
> > break;
> > // I would like this to raise a compilation error as there is no case
> > for MyVar.four
> > }
> >
> > Thanks, Adam
> >
>
>
>

Right, and as I said .. the values are not populated at compile time, so the
compiler has no way of knowing what you might be sending down that code
path. Which is why the default keyword.

In short - not possible to do.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik



"Adam Blair" <(E-Mail Removed)> wrote in message
news:A22F0F3A-1354-496E-8FF9-(E-Mail Removed)...
> What i was after is an indication - at compilation - if there *could ever
be*
> a value of myVar that is not handled.
>
> "Sahil Malik" wrote:
>
> > A compilation error doesn't make sense there since during compile time,
the
> > value of myVar is not populated.
> > You do want a runtime error though, and Debug.Assert is a good
suggestion
> > there. Debug.Assert will not require the developers to look at the
output
> > window.
> >
> > You could always throw an exception for a little bit more intrusive
alert.
> >
> > - Sahil Malik
> > http://dotnetjunkies.com/weblog/sahilmalik
> >
> >
> >
> > "Adam Blair" <Adam (E-Mail Removed)> wrote in message
> > news:4A5AC66A-2913-4156-9C03-(E-Mail Removed)...
> > > Is it possible to bind a switch statement to an Enum such that a
> > compile-time
> > > error is raised if not all values within the Enum are handled in the
> > switch
> > > statement? I realise you can use default: to catch unhandled cases,
but of
> > > course this is only at run-time.
> > >
> > > Example:
> > > public enum MyEnum
> > > {
> > > one, two, three, four
> > > }
> > >
> > > ...
> > >
> > > MyEnum myVar;
> > > switch (myVar)
> > > {
> > > case MyEnum.one:
> > > break;
> > > case MyEnum.two:
> > > break;
> > > case MyEnum.three:
> > > break;
> > > // I would like this to raise a compilation error as there is no
case
> > > for MyVar.four
> > > }
> > >
> > > Thanks, Adam
> > >
> >
> >
> >

My point is that the value myVar *must* be one of the 4 values in the Enum
MyEnum (so the compiler does in fact know what we might be sending down that
code path - it is either one, two, three or four; nothing else) but only 3 of
them are handled by the switch statement. I know that at compilation myVar
has no value, but it is logically possible to determine that the switch
statement does not handle all possible values.

regards, Adam

"Sahil Malik" wrote:

> Right, and as I said .. the values are not populated at compile time, so the
> compiler has no way of knowing what you might be sending down that code
> path. Which is why the default keyword.
>
> In short - not possible to do.
>
> - Sahil Malik
> http://dotnetjunkies.com/weblog/sahilmalik
>
>
>
> "Adam Blair" <(E-Mail Removed)> wrote in message
> news:A22F0F3A-1354-496E-8FF9-(E-Mail Removed)...
> > What i was after is an indication - at compilation - if there *could ever
> be*
> > a value of myVar that is not handled.
> >
> > "Sahil Malik" wrote:
> >
> > > A compilation error doesn't make sense there since during compile time,
> the
> > > value of myVar is not populated.
> > > You do want a runtime error though, and Debug.Assert is a good
> suggestion
> > > there. Debug.Assert will not require the developers to look at the
> output
> > > window.
> > >
> > > You could always throw an exception for a little bit more intrusive
> alert.
> > >
> > > - Sahil Malik
> > > http://dotnetjunkies.com/weblog/sahilmalik
> > >
> > >
> > >
> > > "Adam Blair" <Adam (E-Mail Removed)> wrote in message
> > > news:4A5AC66A-2913-4156-9C03-(E-Mail Removed)...
> > > > Is it possible to bind a switch statement to an Enum such that a
> > > compile-time
> > > > error is raised if not all values within the Enum are handled in the
> > > switch
> > > > statement? I realise you can use default: to catch unhandled cases,
> but of
> > > > course this is only at run-time.
> > > >
> > > > Example:
> > > > public enum MyEnum
> > > > {
> > > > one, two, three, four
> > > > }
> > > >
> > > > ...
> > > >
> > > > MyEnum myVar;
> > > > switch (myVar)
> > > > {
> > > > case MyEnum.one:
> > > > break;
> > > > case MyEnum.two:
> > > > break;
> > > > case MyEnum.three:
> > > > break;
> > > > // I would like this to raise a compilation error as there is no
> case
> > > > for MyVar.four
> > > > }
> > > >
> > > > Thanks, Adam
> > > >
> > >
> > >
> > >
>
>
>

"Adam Blair" <(E-Mail Removed)> wrote in message
news:CAB4F4C8-D344-4628-B4B8-(E-Mail Removed)...
> My point is that the value myVar *must* be one of the 4 values in the Enum
> MyEnum (so the compiler does in fact know what we might be sending down
> that
> code path - it is either one, two, three or four; nothing else)

Unfortunately, that's not the case. myVar can be assigned any value from
the enum's underlying type (usually an integer).


> but only 3 of
> them are handled by the switch statement. I know that at compilation myVar
> has no value, but it is logically possible to determine that the switch
> statement does not handle all possible values.

Your best approach here might be a custom FxCop rule. In addition to
screening for all values from the enum, you might also want to consider
also enforcing using of a default clause to handle possible values that are
not defined by the enum.


> regards, Adam
>
> "Sahil Malik" wrote:
>
>> Right, and as I said .. the values are not populated at compile time, so
>> the
>> compiler has no way of knowing what you might be sending down that code
>> path. Which is why the default keyword.
>>
>> In short - not possible to do.
>>
>> - Sahil Malik
>> http://dotnetjunkies.com/weblog/sahilmalik
>>
>>
>>
>> "Adam Blair" <(E-Mail Removed)> wrote in message
>> news:A22F0F3A-1354-496E-8FF9-(E-Mail Removed)...
>> > What i was after is an indication - at compilation - if there *could
>> > ever
>> be*
>> > a value of myVar that is not handled.
>> >
>> > "Sahil Malik" wrote:
>> >
>> > > A compilation error doesn't make sense there since during compile
>> > > time,
>> the
>> > > value of myVar is not populated.
>> > > You do want a runtime error though, and Debug.Assert is a good
>> suggestion
>> > > there. Debug.Assert will not require the developers to look at the
>> output
>> > > window.
>> > >
>> > > You could always throw an exception for a little bit more intrusive
>> alert.
>> > >
>> > > - Sahil Malik
>> > > http://dotnetjunkies.com/weblog/sahilmalik
>> > >
>> > >
>> > >
>> > > "Adam Blair" <Adam (E-Mail Removed)> wrote in message
>> > > news:4A5AC66A-2913-4156-9C03-(E-Mail Removed)...
>> > > > Is it possible to bind a switch statement to an Enum such that a
>> > > compile-time
>> > > > error is raised if not all values within the Enum are handled in
>> > > > the
>> > > switch
>> > > > statement? I realise you can use default: to catch unhandled cases,
>> but of
>> > > > course this is only at run-time.
>> > > >
>> > > > Example:
>> > > > public enum MyEnum
>> > > > {
>> > > > one, two, three, four
>> > > > }
>> > > >
>> > > > ...
>> > > >
>> > > > MyEnum myVar;
>> > > > switch (myVar)
>> > > > {
>> > > > case MyEnum.one:
>> > > > break;
>> > > > case MyEnum.two:
>> > > > break;
>> > > > case MyEnum.three:
>> > > > break;
>> > > > // I would like this to raise a compilation error as there is
>> > > > no
>> case
>> > > > for MyVar.four
>> > > > }
>> > > >
>> > > > Thanks, Adam
>> > > >
>> > >
>> > >
>> > >
>>
>>
>>

> System.Diagnostics.Debug.Assert(false, "unhandled enum value");

For such things

System.Diagnostics.Debug.Fail("unhandled enum value");

is shorter

"Benoit Vreuninckx" <(E-Mail Removed)> schrieb im Newsbeitrag
news:41dd4bf3$0$2560$(E-Mail Removed)...
> Adam Blair wrote:
> > Is it possible to bind a switch statement to an Enum such that a
compile-time
> > error is raised if not all values within the Enum are handled in the
switch
> > statement? I realise you can use default: to catch unhandled cases, but
of
> > course this is only at run-time.
> >
> > Example:
> > public enum MyEnum
> > {
> > one, two, three, four
> > }
> >
> > ....
> >
> > MyEnum myVar;
> > switch (myVar)
> > {
> > case MyEnum.one:
> > break;
> > case MyEnum.two:
> > break;
> > case MyEnum.three:
> > break;
> > // I would like this to raise a compilation error as there is no
case
>
> default:
> System.Diagnostics.Debug.Assert(false, "unhandled enum value");
> break;
>
> > for MyVar.four
> > }
> >
> > Thanks, Adam
> >
>
> That compiler option does not exist (or I must be unaware of it).
> I suggest calling Debug.Assert(false) in the default clause. This way
> you are notified of any unhandled values, that is, in the debug version
> of your application. The release version will silently ignore the
> assert statement. You could also throw an exception in the default
> case, but this would also happen in the release version, which might not
> be very appealing.
> BTW, I added some code inline.
>
> Cheers,
>
> Benoit.

Sahil Malik wrote:
> Right, and as I said .. the values are not populated at compile time, so the
> compiler has no way of knowing what you might be sending down that code
> path. Which is why the default keyword.
>
> In short - not possible to do.
>
> - Sahil Malik
> http://dotnetjunkies.com/weblog/sahilmalik
>
>
>
> "Adam Blair" <(E-Mail Removed)> wrote in message
> news:A22F0F3A-1354-496E-8FF9-(E-Mail Removed)...
>
>>What i was after is an indication - at compilation - if there *could ever
>
> be*
>
>>a value of myVar that is not handled.
>>
>>"Sahil Malik" wrote:
>>
>>
>>>A compilation error doesn't make sense there since during compile time,
>
> the
>
>>>value of myVar is not populated.
>>>You do want a runtime error though, and Debug.Assert is a good
>
> suggestion
>
>>>there. Debug.Assert will not require the developers to look at the
>
> output
>
>>>window.
>>>
>>>You could always throw an exception for a little bit more intrusive
>
> alert.
>
>>>- Sahil Malik
>>>http://dotnetjunkies.com/weblog/sahilmalik
>>>
>>>
>>>
>>>"Adam Blair" <Adam (E-Mail Removed)> wrote in message
>>>news:4A5AC66A-2913-4156-9C03-(E-Mail Removed)...
>>>
>>>>Is it possible to bind a switch statement to an Enum such that a
>>>
>>>compile-time
>>>
>>>>error is raised if not all values within the Enum are handled in the
>>>
>>>switch
>>>
>>>>statement? I realise you can use default: to catch unhandled cases,
>
> but of
>
>>>>course this is only at run-time.
>>>>
>>>>Example:
>>>>public enum MyEnum
>>>>{
>>>> one, two, three, four
>>>>}
>>>>
>>>>...
>>>>
>>>>MyEnum myVar;
>>>>switch (myVar)
>>>>{
>>>> case MyEnum.one:
>>>> break;
>>>> case MyEnum.two:
>>>> break;
>>>> case MyEnum.three:
>>>> break;
>>>> // I would like this to raise a compilation error as there is no
>
> case
>
>>>>for MyVar.four
>>>>}
>>>>
>>>>Thanks, Adam
>>>>
>>>
>>>
>>>
>
>

Hi,

He just wanted to know if the compiler is able to check if all the
possible values of an enumeration have a corresponding case in the
switch statement. So if one adds a new value to the enumeration, the
compiler should throw a warning/error on all switch statements not
explicitly handling that new value.

Cheers,
Benoit.