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.
Select Case name
Case "FSTF"
.....
Case "FSTF"
.....
End Select
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?
From the documentation for Select...Case:
If
testexpression
matches anexpressionlist
clause in more than oneCase
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...
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With