Throws a FourError when condition is false — in development
builds only.
This is §85's "expensive validation", and the asymmetry is the point: a
production build skips the check entirely rather than checking and
continuing. So devAssert is for mistakes an author must fix before
shipping, never for conditions a shipped program is expected to hit.
The rule for choosing between this and a plain throw new FourError(...):
Unconditional throw when the check is essential safety — the
operation cannot proceed, or proceeding corrupts state. §85 requires these
to survive into production, and every FourError the engine throws today
stays exactly where it is.
devAssert when the check is a scan — walking a hierarchy, testing
every element of an array, re-deriving something to compare it — and the
code below it merely produces a wrong picture rather than a broken engine.
Since the throw disappears in production, never write code whose correctness
depends on it having fired.
Throws a FourError when
conditionis false — in development builds only.This is §85's "expensive validation", and the asymmetry is the point: a production build skips the check entirely rather than checking and continuing. So
devAssertis for mistakes an author must fix before shipping, never for conditions a shipped program is expected to hit.The rule for choosing between this and a plain
throw new FourError(...):FourErrorthe engine throws today stays exactly where it is.devAssertwhen the check is a scan — walking a hierarchy, testing every element of an array, re-deriving something to compare it — and the code below it merely produces a wrong picture rather than a broken engine.Since the throw disappears in production, never write code whose correctness depends on it having fired.