Challenge 2: When a Blanket IFERROR Hides a Genuine Bug — Solution Walkthrough

A realistic scenario where IFERROR(VLOOKUP(...), "") hides a genuine bug:

Suppose the VLOOKUP's table_array was originally B1:C50, and later
someone deletes column C from the worksheet entirely (perhaps
thinking it was unused). The VLOOKUP now genuinely can't run — its
reference is broken, producing a real #REF! error, not a harmless
"value not found." But IFERROR doesn't distinguish between error
TYPES at all — it catches #REF! exactly the same way it would catch
a harmless #N/A, and displays the same blank "" fallback either way.
The cell now just looks empty, exactly as it might if a lookup
legitimately found no match — there is nothing visible anywhere to
suggest the formula itself is actually broken, and the missing data
could go unnoticed for a long time, especially if the blank result
still looks like a plausible "no data for this row" situation rather
than an obvious problem.

The more precise alternative — IFNA:

  =IFNA(VLOOKUP(D2, A:C, 3, FALSE), "")

IFNA only catches a genuine #N/A (a real "no match found"), and lets
every other error type — including the #REF! from the deleted
column — display visibly and unmodified. With IFNA in place, the same
deleted-column scenario would show a plain #REF! error in the cell,
immediately signalling that something structural is actually broken,
rather than quietly presenting a blank cell that looks intentional.

Notes:
- This is exactly this chapter's own warning box in a concrete,
  specific form: the danger of a blanket IFERROR isn't hypothetical —
  it's precisely this kind of "a real structural break gets displayed
  identically to a harmless expected case" scenario.