BASIC & Visual Basic DISCUSSION

VB.NET And versus AndAlso (and Or versus OrElse): why does my null check still throw?

Started by ali VB.NET AndAlsoOrElseshort-circuit evaluationNullReferenceExceptionbitwise And
5 replies 248 views 6 participants
Latest activity · 30 Sep 2026

VB.NET And versus AndAlso (and Or versus OrElse): why does my null check still throw?

#1

In a VB.NET data logger I guard a list with If readings IsNot Nothing And readings.Count > 0 Then. When readings is Nothing the line throws a NullReferenceException, which is exactly what the first test was supposed to prevent. Replacing And with AndAlso fixes it.

What is the difference between the two operators, why does VB have both, and is there any reason to keep using plain And and Or?

Community replies 5

Re: VB.NET And versus AndAlso (and Or versus OrElse): why does my null check still throw?

#2

And always evaluates both operands and then combines them. AndAlso short-circuits: if the left operand is False, the right one is never evaluated. With readings equal to Nothing, And still evaluates readings.Count, hence the exception. Or and OrElse are the same pair for the other case: OrElse skips the right side when the left is already True, as in If s Is Nothing OrElse s.Length = 0 Then.

For conditions in If, While and Do, use the short-circuit forms as the default.

Re: VB.NET And versus AndAlso (and Or versus OrElse): why does my null check still throw?

#3

The reason for two sets is history. In classic Visual Basic, And and Or were never short-circuit, and they double as bitwise operators on integers. VB.NET kept that meaning so that ported code would behave identically, and added AndAlso and OrElse as new keywords for short-circuit logic.

The bitwise role is still the main legitimate use of the old pair: status And &H0F masks the low four bits, 6 And 3 is 2, and flags Or &H80 sets bit 7. AndAlso and OrElse work only on Boolean operands.

Re: VB.NET And versus AndAlso (and Or versus OrElse): why does my null check still throw?

#4

There is one logical case for And: when the right-hand side has an effect that you want regardless. If ValidateName() And ValidateAddress() Then runs both validators so that both error messages appear, where AndAlso would stop after the first failure. That is legitimate but easy to misread, so it is clearer to call both functions into two Boolean variables first and then combine the variables.

Performance is a minor point in favour of short-circuiting: an expensive second test, such as a database lookup or a serial read, is skipped whenever the first test already decides the outcome.

Re: VB.NET And versus AndAlso (and Or versus OrElse): why does my null check still throw?

#5

Watch the mixed case under Option Strict Off. In If flags And 4 Then the And is bitwise, and the integer result is then converted to Boolean, where any non-zero value counts as True. It works, but If flags And 4 = 4 Then does not do what it appears to, because comparison binds tighter than And: it is evaluated as flags And (4 = 4). Write If (flags And 4) <> 0 Then, which also compiles with Option Strict On.

Precedence among the logical operators is Not, then And and AndAlso, then Or and OrElse, so parenthesise any condition that mixes them.

Re: VB.NET And versus AndAlso (and Or versus OrElse): why does my null check still throw?

#6

If you also maintain VBA or VB6 code, remember that those dialects have no AndAlso or OrElse at all. If Not rng Is Nothing And rng.Value > 0 Then fails there with error 91 for the same reason as your VB.NET line, and the only fix is nesting: an outer If Not rng Is Nothing Then with the second test in an inner If.

The same applies to IIf, which is an ordinary function and evaluates all of its arguments before choosing one.

TEP COMMUNITY