5 thoughts on “Another sneak preview of VB 2005 on MSDN…

  1. Mike Gale

    I may hate the naming (My, Me…) but this is getting back to the roots.

    The first versions of VB.NET were from the

    "Why write a line of code when you can write 100 lines (and debug them)"

    school of programming.

    A lot of pragmatic people think that approach a dumb idea. I certainly do.

    Well done. Good to see things back on track after the shakeup.

    (Then give us the extensions to the type system, streams, tuples et al and we’ll get free of some of the remaining shortcoming of traditional OO ideas!!)

    Reply
  2. Christopher Hawkins

    The Error Correction Dialog Box is nice. Those of us who tend to write an entire module straight through (shem) and then go back to smooth it out will make good use fo that feature.

    I have to say, I was completely unenthusiastic about the first go-round of VB.NET. As Mike said above, I got the impression that I had to write twice as much code to get half as much functionality as I did in VB6; admittedly, I may be wrong on this, there might be some important line-reducing feature I missed, but that was my impression, and first impressions count.

    Ken’s write-up makes VB 2005 look as though it’s going to be much more palatable. I’m looking forward to trying it out.

    Reply
  3. Marek Konopka

    All these features are great, but so far for me the most important change are the VB.NET compiler improvements.

    For example the new compiler generates two warnings for the following code:

    Public Class K1

    Public ReadOnly Property Name() As String

    Get

    Dim s As String

    If s.Length > 0 Then

    Return "M1"

    End If

    End Get

    End Property

    End Class

    warning BC42104: Variable ‘s’ is used before it has been assigned a value. A null reference exception could result at runtime.

    warning BC42107: Property ‘Name’ doesn’t return a value on all code paths. A null reference exception could occur at run time when the result is used.

    And you can ask the compiler to treat warnings as errors (which I strongly recommend). In the command line compiler use /warnaserror.

    In VS you can set this through Project properties. On the Compile tab you can see what else is detected and whether it should be treated as warning or error.

    It seems like a small change, but it may help improve programs a lot.

    Reply
  4. Howard C. Shaw, III

    I am not impressed with warning BC42104, and I would never mark it for WarnAsError. It will warn about code like:

    Dim Stream As IO.StreamReader

    Try

    Stream = New IO.StreamReader(filename)

    … do stuff

    Catch ex AS Exception

    Finally

    If Not Stream Is Nothing Then Stream.Close

    End Try

    It will warn on the finally, inside the If Not Is Nothing itself, that Stream may not have been initialized, in spite of the fact that you are testing it.

    On the other hand, it does not complain about this code, which has exactly the error it should be warning about:

    Dim Stream As IO.StreamReader = Nothing

    Try

    Stream = New IO.StreamReader(filename)

    … do stuff

    Catch ex AS Exception

    Finally

    Stream.Close

    End Try

    So assigning Nothing to it, is enough to silence the error, but protecting your code with tests is not. Pretty useless addition, if you ask me.

    Howard C. Shaw, III

    Reply

Leave a Reply