VB Select Case statement incarnation of C# if (true = [condition])
-
I saw this at work. I guess the coder wanted to do a series of validations and return an error when the first failure condition was found. I don't know if you'll consider this a horror or not, but it is definitely a backwards way of doing this.
Select Case (true)
Case [failure condition 1]
Throw New Exception("Condition 1 failed.")
Case [failure condition 2]
Throw New Exception("Condition 2 failed.")
'etc...
Else
'Success!
End Select -
I saw this at work. I guess the coder wanted to do a series of validations and return an error when the first failure condition was found. I don't know if you'll consider this a horror or not, but it is definitely a backwards way of doing this.
Select Case (true)
Case [failure condition 1]
Throw New Exception("Condition 1 failed.")
Case [failure condition 2]
Throw New Exception("Condition 2 failed.")
'etc...
Else
'Success!
End SelectLooks ok for me. Why a backwards way?
Greetings - Gajatko Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
-
Looks ok for me. Why a backwards way?
Greetings - Gajatko Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
Why? Normally the test expression is evaluated at runtime, and the result is compared to each case until a match is found. In my experience, the case expressions are usually constant, and they are usually unique values (in C# & C++ these behaviors are enforced). Here, the test expression is the constant, and the case expressions are calculated at runtime. And, since in the actual example there were several expressions that were returning boolean results, there were several cases that would have the same values. That is what I mean by backward. It certainly works, and maybe it just struck me as odd because my background is predominantly C++ & C#. But, the company I'm at has a large body of VB.NET code and this is the only instance I've seen of a case statement done this way. And, it is backward compared to the example in MSDN as well. It seems like if you want to evaluate a series of expressions until you find one that is true, using an if-then-elseif would be more appropriate. Just my opinion.
-
Why? Normally the test expression is evaluated at runtime, and the result is compared to each case until a match is found. In my experience, the case expressions are usually constant, and they are usually unique values (in C# & C++ these behaviors are enforced). Here, the test expression is the constant, and the case expressions are calculated at runtime. And, since in the actual example there were several expressions that were returning boolean results, there were several cases that would have the same values. That is what I mean by backward. It certainly works, and maybe it just struck me as odd because my background is predominantly C++ & C#. But, the company I'm at has a large body of VB.NET code and this is the only instance I've seen of a case statement done this way. And, it is backward compared to the example in MSDN as well. It seems like if you want to evaluate a series of expressions until you find one that is true, using an if-then-elseif would be more appropriate. Just my opinion.
Of course it wouldn't make sense in neither C++ nor C# code. But since VB doesn't require case expressions to be constant, the syntax above is acceptable. Anyway it's not just your opinion -- I find this odd and confusing too. On the other side, I am not a VB guy and maybe it's normal to them and you have to get used to
Switch (True)mess.Greetings - Gajatko Portable.NET is part of DotGNU, a project to build a complete Free Software replacement for .NET - a system that truly belongs to the developers.
-
I saw this at work. I guess the coder wanted to do a series of validations and return an error when the first failure condition was found. I don't know if you'll consider this a horror or not, but it is definitely a backwards way of doing this.
Select Case (true)
Case [failure condition 1]
Throw New Exception("Condition 1 failed.")
Case [failure condition 2]
Throw New Exception("Condition 2 failed.")
'etc...
Else
'Success!
End SelectPerhaps more interesting would be a use I've seen suggested for "Catch ... When" in vb.net: have the "When" clause invoke a function which logs the exception and always returns true (if the goal is to catch the exception, but use a centralized logging facility) or always returns false (if the goal is to log the exception and related information without having to catch and rethrow the exception).
-
I saw this at work. I guess the coder wanted to do a series of validations and return an error when the first failure condition was found. I don't know if you'll consider this a horror or not, but it is definitely a backwards way of doing this.
Select Case (true)
Case [failure condition 1]
Throw New Exception("Condition 1 failed.")
Case [failure condition 2]
Throw New Exception("Condition 2 failed.")
'etc...
Else
'Success!
End SelectThink of it as
If ElseIfstatements with uniform indentation of the conditionals. Of course in this case it could be reduced to:If [failure condition 1] Then _
Throw New Exception("Condition 1 failed.")If [failure condition 2] Then _
Throw New Exception("Condition 2 failed.")'etc...
'Success!
But in defence of
Select Case True, it used to be the easiest way to get short-circuiting in VB6. Could this code have been around long enough to have been converted?Regards, Mark Hurd, B.Sc.(Ma.) (Hons.)