UndefinedMemberD4rtException class

Thrown when a member lookup finds no member of that name on the receiver.

This is a control-flow signal, and that is the reason it exists. Eight sites in each mirrored visitor have to distinguish "the member is genuinely absent, so try extension-method resolution" from "the member was found and something inside it failed, so propagate that". Before SCC28 they made that decision with e.message.contains("Undefined property '$name'") — a formatted, human-readable diagnostic used as a branch condition. The wording was therefore load-bearing: rewording it, in either tree, silently disabled extension methods for every receiver kind routed through the edited site, with no analyzer error and a wrong answer rather than a crash as the symptom.

memberName carries what the message used to spell, so the message is free to change. It is compared exactly (e.memberName == name) where the old code asked for a substring, which also removes the case where a member whose name merely appeared in an unrelated diagnostic took the extension branch.

A subtype of RuntimeD4rtException, deliberately. Between a raise site and the site that inspects it sit roughly forty on RuntimeD4rtException clauses, most of which only re-wrap and re-throw. Making this a sibling type would have required changing all of them in one commit; making it a subtype let the conversion land raise site by raise site, with every intermediate state working. toString() is inherited too, so the diagnostics are unchanged to the byte and no message assertion needed rewriting.

Not to be confused with D4rtNoSuchMethodError, which the final lookup failures raise — the ones reached after extension resolution and any user noSuchMethod have had their chance. This type marks the intermediate failures, the ones that are still a question rather than an answer. Catchable as NoSuchMethodError, like D4rtNoSuchMethodError (sce67). Asking a receiver for a member it does not have used to report two ways decided by the member KIND rather than by anything a script can see: a missing METHOD raised D4rtNoSuchMethodError and was catchable as the SDK type, a missing GETTER raised this and was not. So try { ... } on NoSuchMethodError catch (_) handled one half of the same failure and missed the other. F-SCC8-5's reasoning — "a missing member is the same failure real Dart reports at runtime, and asserting the SDK supertype means a script can catch it the way it would catch the real one" — does not stop applying at getters.

The supertype is ADDED, not swapped: this stays a RuntimeD4rtException, so every existing on RuntimeD4rtException clause and every internal is UndefinedMemberD4rtException test is unaffected. Those internal tests are why the intermediate/final distinction below still holds — they select on this exact type, never on the SDK supertype.

STATIC member absence is deliberately NOT given this supertype, and nor is UndefinedNameD4rtException (scc31). Real Dart rejects Klass.missing and a bare undefined name at COMPILE time, so there is no runtime NoSuchMethodError for a script to catch; inventing one would make d4rt strictly more catchable than the platform, which is the mistake D4rtRangeError records for IndexError. Instance access is different: d4rt receivers are effectively dynamic, and dynamic access to a missing member IS a runtime NoSuchMethodError in real Dart.