Greetings,

If x = y And m = n The
....
End If

If x = y AndAlso m = n Then
....
End If

When do I need to use AndAlso vs And?

Thanks,
Rich

For the sample you provided, you are doing a strictly logical operation.  Use
the "AndAlso" since it's more efficient (it doesn't evaluate the second
operand if the first is false).
The "And" operator is usually just used for bitwise operations.  You can
also use "And" for logical operations, but it evaluates both operands always.
Show quoteHide quote

If you use "And", then it processes all of the clauses and then decides
if it's true or not.
So it checks both (x=y) and (m=n).

If you use "AndAlso", it stops processing when it hits a condition that
is false. So if (x=y)
is false, it never checks (m=n). This is more efficient because it
doesn't do
unnecessary processing, and also can be handy, if you want to do
something like this:

If (rdr IsNot Nothing) AndAlso rdr.Rows(0).Items(0).ToString = "abc" ...

Unlike VB6, it won't crap out if rdr is nothing, because it won't
process the
second clause.

For the "or" operator, they added "OrElse" which does the same thing.
It's called short-circuiting.

I believe this is the way "and" and "or" work in C/C++/C#. I think they
would
have just changed "and" and "or" in VB, but it would have freaked out
too many
people and required more work when converting from VB6, so they just
added
new constructs.

Robin S.
(more info than you wanted, wasn't it?)
------------------------------

Show quoteHide quote

Thank you all for your replies and information.  This was very useful.  I was
going to add the part about "OR".  So thanks for the info on that, too.  It
all makes sense now.  Basically it sounds like I should just use AndAlso and
OrElse for everything.  I can do that.  I just didn't understand if there was
a difference up to now. 

Rich

Show quoteHide quote

Rich wrote:

RobinS explained how those keywords work so I won't repeat that
information.  My recommendation is to ALWAYS use AndAlso and OrElse
when doing logical comparisons.  It costs you nothing to use them and
you get the benefits of short circuiting.

Use And and Or for bitwise operations.

The exception being if you are reusing code from VB6 and it might not
be worth the time to change the And's and Or's to AndAlso and OrElse.

Chris

While I concur with the 'use AndAlso and OrElse when doing logical
comparisons' rule of thumb, as usual there are always exceptions to the
rule.

One such exception is the situation where one has 2 functions where both
return a boolean, both execute some code that is critical to the application
and the result of both must be True for some other action to be taken, e.g.:

  Private Sub Form_Load(...) Handles MyBase.Load

    If FunctionA() And FunctionB() Then
      ' Take some critical action before continuing
    End If

  End Sub

  Private Function FunctionA() As Boolean

    Try
      ' Some critical code here
      Return True
    Catch
      Return False
    End Try

  End Function

  Private Function FunctionB() As Boolean

    Try
      ' Some other critical code here
      Return True
    Catch
      Return False
    End Try

  End Function

If AndAlso was used in this case, and FunctionA returned False then
FunctionB would not be called and a critical step would be 'missed'.

I am not advocation that this is a good way to go about things, merely that
it demonstrates a situation where 'short-circuiting' is not desirable.


Show quoteHide quote

What about AndNotAlsoProvided?

George

Chris Dunaway wrote:
Show quoteHide quote

Unless you have a desired side effect of all parts of the expression getting
performed reguardless so that a function gets called.

However,

This sort of "side effect" programming, is questionable at best and can be
harder to debug for others.  Usually it's best to short circuit.

This is a great addition to VB and I use it alot.
I used to have to jump some whoops to use AND because each item would get
evaluated reguardless.

For example:

If not objectX is nothing AND objectX.method=something then

This would blow up if objectX was nothing, because it would always try to
hit part two of the condition.

The same thing written like:
If not objectX is nothing ANDALSO objectX.method=something then

would have no problem because if objectX is nothing then it would stop
before trying to access a method/property on it.

-Shane
<george_w_bl***@yahoo.com.sg> wrote in message
Show quoteHide quote

Just a Program
System Restore
Premature Ending of App
label transperent problem
Beginner help with FolderBrowserDialog
check if table is empty
VB.Net application deployment
XML to Listbox
C# function be converted to VB.NET
C# function be converted to VB.NET