Guest Opinion

Read This -- OrElse

VB differs from other .NET-languages in that it doesn't provide short-circuited conditional statements, but you can still achieve the same effect, and be backward compatible with pre-.NET versions of VB.

• By Billy Hollis
• 06/01/2006

As a speaker and author who is well-known for his association with Visual Basic, I get no small amount of mail from VB's detractors.

Some of the criticism is fair, most of it isn't, and every criticism is a chance to evangelize the language. Hey, at least people are talking to me about VB! One topic that elicits catcalls from VB's detractors is VB's reliance on the OrElse keyword. It's easy enough to make fun of this keyword, but the criticism is only half-right (like many criticisms you hear about VB).

The initial betas for VB.NET reflected the fact that Microsoft wanted to give VB a capability most other languages already had. Given the logical condition "x AND y," it's not necessary to evaluate y if x is False. In this case, you know the overall result is False, regardless of what y is. Similarly, given the condition "u OR v," you know it's unnecessary to evaluate v if u is True. Other languages have a way to take advantage of this. They have logical operators that avoid evaluating the second part of such a conditional when it's unnecessary. People commonly call these short-circuited conditionals.

I like short-circuited conditionals, but VB Classic doesn't support them. If you have condition "x AND y," and x is False the runtime still evaluates y.

You might think this is hair splitting, but it leads to a difference in behavior. Assume the second part of the conditional involves a call to a function that returns a Boolean. Furthermore, suppose the function does something that you want to happen:

If bSomeBoolean And DoesSomething() Then

If bSomeBoolean is False, but the And is short-circuited, then DoesSomething() never runs. But this function is guaranteed to run in all versions of Visual Basic if the line executes, regardless of the value of bSomeBoolean. The same is true if you have an Or, and bSomeBoolean is True:

If bSomeBoolean Or DoesSomething() Then

Any language using a short-circuited logical operator works differently in both cases. The difference is notable only if you put some action-oriented function in the second conditional. I never do this; instead, I'd have written the line like this in VB Classic:

Dim bAnotherBoolean As Boolean
bAnotherBoolean = DoesSomething()
If bSomeBoolean And bAnotherBoolean Then

This code is longer, but it's also much easier to read. I usually prefer something long and easier to read over something short and cryptic.

But not everybody codes the same way. There are many billions of lines of VB Classic code out there. And you can find many examples where the developer attached an action to a conditional in a manner that, changing the operation of the "And" and "Or" keywords, would cause incompatibilities when you bring the code to .NET. So complaints from VB.NET's early betas led Microsoft to revert to the traditional manner of handling conditional statements in VB.

This change was understandable, but left us with a problem. There are times when you need to use a short-circuited conditional:

If IsDBNull(drADataRow.Item("AField")) Or _
drADataRow.Item("AField").ToString.Length = 0 Then

This line fails in VB if the item is null because the second part of the conditional can't work with a null item, but it works fine with a short-circuited Or. Fortunately, Microsoft created a new keyword to enable short-circuiting when it reverted back to VB Classic behavior: OrElse. You don't see it used much, but it can help you address the situation I've been describing:

If IsDBNull(drADataRow.Item("AField")) OrElse _
drADataRow.Item("AField").ToString.Length = 0 Then

The first part evaluates to True if the data item is null, so the second part never executes. Similarly, the .NET version of VB includes an AndAlso keyword for a short-circuited And. You see it even less often than OrElse because its behavior is easily replicated with a nested If.

I agree with the folks who think VB's conditionals should be short-circuited, but that's water under the bridge at this point. You can get short-circuiting anyway with the AndAlso and OrElse keywords, while still maintaining backward compatibility with your older, pre-.NET code. It's an imperfect compromise, maybe, but it's a compromise with a little something for everyone—which is perhaps exactly what you expect from VB as a language.