VB Unreachable code error/warning

Question

I've been mostly working with VB.Net for over a year and just noticed this

Am I going insane, or does VB.Net NOT have an "Unreachable code" warning?

The following compiles quite happily with nary a warning or error, even though there is a return between the two writeline calls.

Sub Main()
    Console.WriteLine("Hello World")
    Return
    Console.WriteLine("Unreachable code, will never run")
End Sub

Am I missing something? Is there some way to switch this on that I can't find.

If not, is there a good reason for it's omission? (i.e. or am I right in thinking this is a woeful state of affairs)

Forgive the air of rant about this question, it's not a rant, I would like an answer.

Thanks

---

I've raised this on MS Connect, as bug# 428529

Update

I received the following from the VB Teams program manager

Thanks for taking the time to report this issue. The compiler has limited support for this scenario, and as you point out we don't have warnings for unreachable code. There are some scenarios that our flow analysis algorithm does handle, such as the following:

Sub Main()
    Dim x As Integer
    Return
    x = 4
End Sub

In this case you'll get a warning that x has never been assigned. For the case you mentioned however we'll have to look at implementing that for a future release.

Answer 1

AFAIK, you are correct that VB.NET does not give you a warning. C# does though.

Answer 2

My guess is that it's an oversight in the compiler. Flow control is a very difficult problem to get correct in any language, but especially in a language like VB which has so many different flow control mechanisms. For instance,

• Exceptions
• Goto
• On Error (Resume, Goto, etc ...)
• Exit calls

If you feel strongly about this issue, please file a bug on Connect. We do take bugs filed via Connect very seriously and do our best to fix as many as possible.

Answer 3

They mention this in the following post:

http://stackoverflow.com/questions/210187/usage-statistics-c-versus-vb-net

See the last post.

I guess you could use FXCop to check your code instead or get a copy of Resharper from:

http://www.jetbrains.com/resharper/

Answer 4

I'd like to address Jared's answer.

Most of the issues he brings up are not problematic for data flow analysis.

The one exception is "On Error / Resume". They mess up data flow analysis pretty bad.

However, it's a pretty simple problem to mitigate:

If more than one "On Error" statement is used in a method, or the "Resume next" statement is used, you can just turn off data flow analysis and report a generic warning. A good one might be something like "On Error / Resume are deprecated, use exceptions instead." :)

In the common case of one only "On Error" statement and no "resume" statement, you can pretty much do normal data flow analysis, and should get reasonable results from it.

The big problem is with the way the existing DFA code is implemented. It doesn't use a control flow graph, and so changing it ends up being really expensive. I think if you want to address these kinds of issues you really need rip out the existing DFA code and replace it with something that uses a control flow graph.