Brian Webster Brian Webster - 6 months ago 15
Vb.net Question

VB.NET - IIF(,,) - Both "sides" are evaluated. What situations should I watch out for?

I recently learned of the IIF(A,B,C) function. I'm a long time VB/VB.NET Coder who recently spent a lot of time coming up to speed in SQL coding.

One (obvious) common thing to do in SQL is something like the following:

select (case where @var = 0 then MyTable.Val1 else MyTable.Val2 end) from MyTable


IIF(A,B,C) will allow me to do this in VB.NET... all on one line.

However, I have read that both B and C are evaluated no matter what A evaluates to.

I can think of some obvious situations where this is a bad thing such as:

Dim X as integer = IIF(SomeBoolean = true, ExpensiveFunction1(), ExpensiveFunction2())


As I will be including this in my repertoire, are there any more subtle situations where I may get myself into trouble using IIF?

It's a pretty big departure in some situations from using the old fashioned:

Dim X as integer
if SomeBoolean = true then
X = ExpensiveFunction1()
else
X = ExpensiveFunction2()
end if


I'm hoping to save myself some annoying performance issues and/or bugs in the future.

Update 2016



For the past few years, a new VB.NET feature exists which eliminates the need to use the IIF() function.

if(Something = true, ExecuteA(), ExecuteB())


Only ExecuteA() OR ExecuteB() are executed. Finally, inline IF with shortcircuiting.

So, if you are using later versions of VB.NET (as of 2016), use this instead if you can.

Answer

Here is the most common gotcha.

Z = iif(y=0, 0, x/y)  'Throws a divide by zero exception when y is 0

Don't use it to avoid division by zero errors.

Another possible logic bug is when one side of the iif or the other calls a method that modifies the system state or has output parameters.

Z = iif(FunctionA(InputOutputParam), FunctionB(InputOutputParam))
'InputOutputParam is indeterminate or at least ambiguous here.

There really is no good reason to use IIF in my experience. Mostly it is just used to abbreviate code and given the problems it can cause, it just isn't worth it. Plus, I think it makes the code harder to read.

The other thing that bites is that it returns a boxed value (ie an Object data type) which you have to cast back to the desired type.