6

I am converting some VB.NET code to C#, as I am more comfortable with it and it helps me in resolving issues faster. However, I came across this code which is NOT an error in VB.NET — but converting it to C# is generating a compiler error.

VB.NET Code

Select Case name
    Case "FSTF"
    .....
    Case "FSTF"
    .....
End Select

C# Converted Code

switch(name) {
    case "FSTF":
        ....;
        break;
    case "FSTF":
        ....;
        break;
}

And the error is:

The Label 'case "FSTF":' already occurs in this switch statement.

What is the solution here — does it mean that in the VB.NET code, the second case statement was just a dummy — or was the first case a dummy?

Ry-
  • 218,210
  • 55
  • 464
  • 476
Sekhar
  • 5,614
  • 9
  • 38
  • 44
  • What do you mean "was just dummy"? – jcolebrand Aug 11 '11 at 18:02
  • if i have the following statements int a; a=1; a=2; then I would believe that the statement a=1 is dummy - as it's makes no sense to execute that statement; I know that without the information about the statements (function calls etc) - it would be difficult to tell ... so my question was which one is executed first, and which one next? – Sekhar Aug 11 '11 at 18:04
  • I have _never_ heard that term. – jcolebrand Aug 11 '11 at 18:05
  • I know - my wording was wrong. I meant something like NOP – Sekhar Aug 11 '11 at 18:08
  • 4
    `dummy` from `dumb` meaning `unable to speak`. a `dummy` then became a mock of a human (also mannequin or puppet). Eventually anything that was a mock or placeholder of something became a dummy. `Lorem ipsum` is often called `dummy copy` or `dummy text`. And then eventually anything non-functional. In coding, this comes down to a NOOP as @user331225 said. – Chris Haas Aug 11 '11 at 18:19
  • 3
    I think the real question here is: In VB.NET, what happens when 2 Case sections have the same label? – Joe Aug 11 '11 at 18:22

2 Answers2

13

From the documentation for Select...Case:

If testexpression matches an expressionlist clause in more than one Case clause, only the statements following the first match run.

So here the second case is effectively redundant. Personally I prefer the C# approach of highlighting what was almost certainly an unnoticed programming error rather than the deliberate introduction of a duplicate case...

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • thanks for the link to the documentation! anyway that I can make vb.net generate compiler error for such things?? – Sekhar Aug 11 '11 at 18:29
  • @user331225: Not that I'm aware of. – Jon Skeet Aug 11 '11 at 18:29
  • 4
    VB.Net allows one "Case" statement to accept a range of values (e.g. 6 to 10, or >9), and also allows case statements to use non-constant expressions. While it might be helpful to have a warning when static analysis would show a particular case could never occur, the legitimacy of code should not depend upon a compiler's ability to analyze it. – supercat Aug 11 '11 at 21:09
  • @user331225 you can write you own analyzer which uses Roslyn compiler's API, though it will require a significant effort. – Tomasz Maczyński Jun 25 '16 at 16:39
2

I assume it was done this way to make VB.NET compatible with the Visual Basic 6.0 and older versions because that is the way they behaved. Had VB.NET reported a compilation error like C# then it would have been more difficult to port older Visual Basic code to VB.NET.

The odd thing about this is that VB.NET does not seem smart enough to eliminate the redundant case in the generated CIL code. This leads to another peculiar difference between C# and VB.NET. That is, VB.NET does not change its strategy from a sequential lookup to a Dictionary lookup when targeting string types like C#. This means VB.NET's Select constructs using string types can be slower to execute than C#'s switch counterpart. The reason for this (credit given to MarkJ) is because C# case statements can only contain constants whereas Visual Basic case statements can contain expressions.

Community
  • 1
  • 1
Brian Gideon
  • 47,849
  • 13
  • 107
  • 150
  • 3
    C# `case` statements must be constant expressions, so the C# compiler can emit code that caches the `Dictionary` for later reuse. VB.Net `Case` statements can be expressions, so the VB compiler *can't* use that strategy in the general case. – MarkJ Aug 11 '11 at 22:41