Shout!

WARNING! This blog post is written in anger and frustration !WARNING

I'm currently recovering from a near VB.NET experience. In a Swedish forum somebody asked about casts from DbNull to concrete types and I decided to swiftly put together an example function that could be reused. The swiftly part was quickly omitted in the so called RAD environment of VB.NET. Here is the story about why.

The function I was about to write was a simple check to see if the input parameter value of the type object was in the concrete form of DbNull. If it was, I would return 0 else it would use the Convert.ToInt64 function to return a Long (Yes I know that Int64.TryParse probably would've solved this quickly but I didn't go down that path for this example).

Since I've used VB and VB.NET some before I know about the IS operator and I know about the IIF function built into the language. So my first attempt looked something like this:

Return IIF ( value Is DbNull, 0, Convert.ToInt64(value) )

Standard C# code converted into VB.NET. Now that didn't compile at all in VB.NET, apparently the type name DbNull was not possible to use in the context of Is, that's fine by me. I didn't like the syntax semantics but it was purely syntax, nothing else. So I tried to use the typeof operator:

Return IIF( value Is typeof(DbNull), 0, Convert.ToInt64(value) )

No compile there either, it turns out that typeof has to be before an Is statement and can only be applied to objects. Now why I would need typeof to work for objects when there is an object.GetType() eludes me but so far it's all about my inexperience with VB.NET syntax and its quirks (it also annoys me that there is a Mid when we have string.Substring in the framework but that is another post ).

I found another keyword that supposedly would help me out; GetType, it works more like the typeof does in C# so I tried this out:

Return IIF(value is GetType(DbNull), 0, Convert.ToInt64(value) )

That actually compiled; joy! But function wise it failed miserably. The convert was always called regardless of the type the object variable contained. I factored out the type check to a regular If statement and discovered something that got me really puzzled.

If i changed it to Value Is GetType(object) it returned true. My god! It actually returned a check on the declaration of the parameter, not a check against the actual object type... That gave me a serious headache. Still using the factored out version I changed the type check again to instead make sure I get the concrete type out of the variable
:
If typeof ( value ) is DbNull then

That gave me the expected result, what a relief! My trip to VB World would soon be over. I refactored the code back to using the IIF function:

Return ( typeof ( value ) is DbNull, 0, Convert.ToInt64(value) )

I compiled and run it and it blew up in my face. GAH! Frustration! At this point I was about to give up, how is it possible that a type check that works in a regular If statement would fail in the IIF call!?

Some quick research gave me the answer, it didn't differ how the type check works. It turns out that the IIF function is one of the most stupid functions in the whole language. It does not care about your check at all; it goes ahead and evaluates both the false and the true part of the IIF statement regardless of the expression result.

Why would I want that kind of behavior? One of the reasons for using an if statement in the first place is to shield away the parts from each other, in my case it actually tried to convert to long although the check showed that it would not succeed.

A quick summary; type checks is really not intuitive in VB.NET, with special behaviors it actually confuses the heck out of programmers, no how's that for an "entry level language"? Additionally VB.NET functions are really stupid and doesn't do what they appear to do, they do something else. In a later post I'll show what =, Mid and other VB stuff really does.

Down with VB.NET! Long live C#!

Comments (11)

Vb.Net cons

Tuesday, March 01, 2005

Recently I?ve been arguing in different forums that I think that VB.NET hides implementation details to the obscure. I?ve argued that due to that hide and seek; many vb.net developers never fully understand the nature of .NET.

One example where this is obvious is the Handles keyword.

As many of you probably know, event handling in .NET is implemented using delegates and delegate instance variables. The semantics in handling events is that you hook a function pointer (delegate) to the event using the syntax;

btnAdd.Click += new EventHandler(btnAdd_Click);

Now this isn?t possible in VB.NET 1.x since it doesn?t support operator overloading. Therefore instead they got the AddHandler keyword which is a wrapper to the above C# syntax. That is all fine and dandy. The problem is the following syntax;

       Sub btnAdd_Click(object sender, EventArgs e) Handles btnAdd.Click
            ? Do stuff
      End Sub

Just looking at this without assuming knowledge of the C# syntax and the delegate implementation; I would read this as the method being the controlling party in the event handling process. This is of course wrong, but I do believe that the syntax above does encourage that kind of thinking. Especially if you come from a VB6 background where the method WAS the controlling party from a developer standpoint.

Additionally this actually hides the delegate implementation totally and a developer will be surprised when delegate details do matter in their event handling. I encounter this a lot when I deliver courses, Vb.Net developers has less understanding about delegates then their C# colleagues.

Johan Lindfors (MSFT) challenged me on this standpoint today at MSDN Live in Örebro after I promoted another simplification in C# 2.0:

btnAdd.Click += btnAdd_Click;

The difference as I see it is that with this syntax you will know who the controlling party is and you will actually use a delegate like syntax. A more direct and pedagogic approach which forces the developer to learn the basics.

Speaking of 2.0; in the next version of Vb.Net, Microsoft is introducing more simplifying features. I?m talking about the Microsoft.VisualBasic.MyServices classes. This is a nice tool to have but it also, in my opinion, has a tendency to hide too many details. A classic example is the FileSystem class which blesses the Vb.Net developer with ignorance about streams, which are a central part of the .Net framework and crucial knowledge.

I?m not saying that help and easy programming is a bad thing, I?m just arguing that there?s a danger in over simplifying programming so that important concepts and understanding get lost.

I also want to encourage you to always look at the implementation details before you use any kind of simplification, having the ?know how? greatly reduces the headache when you need to find bugs in you?re simplified code.

Comments (1)