Q:

What do you think when a Boolean "if" has three resulting code paths?

QA tester was reading HTML/JS code to write a functional test of a web form, and saw:
if (form_field == empty)
{
...do stuff for empty field
}
else if (form_field != empty)
{
...do stuff for non-empty field
}
else
{
...do stuff that will never be done
}

After a couple embarrassing attempts, tester realized that they couldn't trigger the alert strings hidden in the third block.
Things I'm wondering are if this Is this problem more or less language specific (can non-JS people learn lessons here?) and are there legitimate reasons code ended up this way?
How can I find/address the problem?

A:

Although the third block can't trigger in Javascript, that is not true in all languages. In T-SQL:
declare @test as int

set @test = null

if @test = 1 
  print 1
else if not @test = 1
  print 2
else 
  print 3

This will print 3, because NULL is neither equal to, nor not equal to any other value.

A:

This can happen if you use poorly designed booleans (common in early C when there wasn't a true boolean type).  You can still find this stuff in Windows.
BOOL result = SomeWindowsAPI();
if (result == TRUE)
{
    // success
}
else if (result == FALSE)
{
    // failure
}
else
{
    // wtf?
}

The key here is the explicit testing for "TRUE" which assumes that there is one and only one way the boolean can have a true value.  When using integers as booleans, this isn't true.
In some languages on some computers (Fortran on VMS), there can be many different integer values that resolve to true and many different values resolve to false.  On Windows, the HRESULT when being interpreted as SUCCESS or FAILURE is the same way.

A:

I've seen cases where the else if used to have something else (AND/OR) there and the person who fixed it just 'fixed it' and didn't probe very deep.

