Panopticon Central

# re: Another sneak preview of VB 2005 on MSDN...

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!!) 6/23/2004 4:01 PM | Mike Gale

# re: Another sneak preview of VB 2005 on MSDN...

I love these new features!
6/26/2004 10:57 PM | Fan

# re: Another sneak preview of VB 2005 on MSDN...

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.

6/29/2004 9:08 AM | Christopher Hawkins

# re: Another sneak preview of VB 2005 on MSDN...

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.
7/3/2004 4:27 AM | Marek Konopka

# re: Another sneak preview of VB 2005 on MSDN...

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 2/26/2007 9:31 AM | Howard C. Shaw, III