In Selenium, why does a WebDriverWait on a wrong locator fail with TimeoutException rather than NoSuchElementException?

## The default ignored set `WebDriverWait`'s constructor does one thing beyond recording the timeout and the interval: it registers **`NotFoundException`** as an ignored exception type. That single registration is why a wait behaves the way it does around missing elements. - `NoSuchElementException` extends `NotFoundException`, so a lookup inside the condition that finds nothing is caught by the loop rather than escaping it. - Its siblings are covered too — `NoSuchFrameException` and `NoSuchWindowException` are also `NotFoundException` subclasses. - `NotFoundException` itself extends `WebDriverException`, but the ignore rule is on the narrower type: being a `WebDriverException` is not enough to be tolerated. - Nothing else is ignored unless you widen the set yourself. ## What happens on each miss When the condition throws an ignored type, the loop does not fail. It: 1. Catches the exception and stores it as the *last exception seen*. 2. Checks the clock against the deadline exactly as it would after a `null` result. 3. Sleeps the polling interval and evaluates the condition again. 4. On timeout, attaches that stored exception as the **cause** of the `TimeoutException`. So a wait on `By.id("preorder-confirmaton")` — one letter short of the real bakery banner id — throws not-found on every attempt, is forgiven every time, and ends after the whole timeout with a `TimeoutException` whose cause is a `NoSuchElementException`. The mistyped locator never surfaces under its own name. ## Reading the cause is the whole diagnosis The loop clears the stored exception whenever an attempt completes cleanly, which turns the cause into a reliable two-way signal: | Cause of the `TimeoutException` | What it means | Where to look | |---|---|---| | `NoSuchElementException` | no attempt ever located anything | the locator, the frame, the page you are actually on | | `null` | attempts ran cleanly, the value was never usable | the application's state — it genuinely never got there | A team that reads only the top line of the stack trace loses this entirely and treats every wait failure as slowness, which sends them looking at the application when the fault is in the test. ## What is *not* ignored, and why it matters `StaleElementReferenceException` is a `WebDriverException`, not a `NotFoundException`. A default `WebDriverWait` therefore does **not** tolerate it: the first time a condition touches an element that has been detached — because the bakery pre-order form re-rendered its slot list underneath it — that exception escapes `until()` immediately and the wait dies well before its deadline. - The same is true of any other non-`NotFoundException` failure raised inside the condition: a scripting error, an invalid selector, an interaction error. - This is a frequent source of confusion, because people describe explicit waits as "retrying until it works" and are then surprised that one particular exception blows straight through. - The behaviour is a deliberate default rather than an oversight: a not-found is an expected intermediate state on a page that is still assembling, while most other failures indicate the test asked something incoherent. ## The operational cost of a forgiven miss Ignoring not-found is what makes waits usable, but it has a price that shows up in production suites: - Every wrong locator costs its **full timeout** before reporting, so a suite with a handful of stale selectors is slow as well as red. - The failure arrives late and generically, which is why the cause chain matters so much for triage. - An assertion that something is *absent*, written as a wait that must fail, deliberately pays the whole deadline every time it passes — an inversion worth being aware of when reasoning about a wait's cost. - Because the miss is swallowed, a wait can be pointing at the wrong frame or the wrong page for its entire duration without any signal until the very end. ## What a strong answer sounds like Say the mechanism, not just the symptom: the wait registers `NotFoundException` as ignored, so each miss is caught, recorded and retried; the recorded exception becomes the cause of the `TimeoutException`; and the presence or absence of that cause tells you whether the locator was wrong or the application was slow. Then add the boundary — `StaleElementReferenceException` is not in that set and escapes immediately — because that is the part that shows you know where the tolerance stops rather than assuming a wait forgives everything.