Questions: Else-If Chains and Multiple Conditions

Question 1

A programmer writes the following grading logic: `if (score >= 60) { grade = 'D' } else if (score >= 70) { grade = 'C' } else if (score >= 80) { grade = 'B' } else if (score >= 90) { grade = 'A' }`. A student scores 93. What grade do they receive?

• A. A — because 93 >= 90 is the most specific matching condition
• B. D — because 93 >= 60 is true and is the first condition checked
• C. B — because the chain averages the matching conditions
• D. No grade — the chain finds multiple matches and produces an error

Answer: (B)

Evaluation stops at the first true condition. Since `93 >= 60` is true, the first branch executes and grade is set to 'D'. The chain never reaches the `>= 90` condition. This is the classic order-of-conditions bug: conditions are tested from least restrictive to most restrictive, so the broad `>= 60` catches everything, and the specific `>= 90` is unreachable for any passing score. The fix is to reverse the order: test `>= 90` first, then `>= 80`, then `>= 70`, then `>= 60`.

Question 2

When should you choose an else-if chain over multiple independent if statements?

• A. Always — else-if chains are strictly better than multiple if statements in every situation
• B. When the conditions are mutually exclusive and you want exactly one branch to execute per run
• C. When the conditions overlap and you want all matching branches to execute
• D. Only when you have exactly three conditions — else-if chains with more conditions should use switch statements instead

Answer: (B)

Use an else-if chain when conditions are mutually exclusive and only one should execute. A grading system (a score belongs to exactly one letter grade) is the canonical example. Use multiple independent if statements when conditions are independent and multiple could legitimately apply — for instance, checking if a number is both even AND greater than 10 requires two separate ifs. The choice is a design decision about whether your conditions can overlap, not a matter of one being strictly better.

Question 3

In an else-if chain, most conditions are evaluated most of the time the chain runs, regardless of which condition is true.

• T. True
• F. False

Answer: False

Evaluation stops at the first true condition. This is the defining property of an else-if chain. Once the first true condition is found, its block executes and the rest of the chain is completely skipped. This early exit is what makes the order of conditions so important: if a broad condition appears first, narrower conditions later in the chain may never be evaluated. The same early-exit behavior is why else-if chains are more efficient than multiple independent ifs when you know conditions are mutually exclusive.

Question 4

The order in which conditions appear in an else-if chain has no effect on program correctness, as long as the conditions cover most cases.

• T. True
• F. False

Answer: False

Order is critical. Even when conditions collectively cover all cases, the wrong order produces wrong output. Consider testing score ranges: if `score >= 60` appears before `score >= 90`, a score of 95 matches the first condition and never reaches the 'A' branch — producing a wrong grade even though the condition `score >= 90` exists in the chain. Correct behavior requires testing the most restrictive (narrowest) conditions first. 'Covering all cases' is necessary but not sufficient — the right case must be reached before any broader case swallows it.

Question 5

Explain why an else-if chain with poorly ordered conditions can silently produce wrong output instead of an error, and how you would detect or prevent this bug.

Model answer: A poorly ordered else-if chain silently gives wrong output because no error occurs — the program simply matches the wrong condition and runs that block. For example, `if (score >= 60) { grade = 'D' }` followed by `if (score >= 90) { grade = 'A' }` doesn't crash when score is 95; it just assigns 'D' instead of 'A'. Detection: test boundary values (e.g., 90, 91, 60, 59) and verify the output matches the intended grades. Prevention: always write conditions from most restrictive to least restrictive, so broader conditions cannot 'swallow' more specific ones that appear later.

The silent-failure aspect is what makes this bug dangerous — it doesn't produce an obvious error message, just wrong behavior. This is a common pattern in conditional bugs generally: logic errors are harder to catch than syntax errors because the program runs successfully, just incorrectly. Testing at boundary conditions (the exact threshold values) is the standard technique for catching this class of bug.