Returns value is RollParserError & {
code:
| "UNEXPECTED_CHARACTER"
| "UNEXPECTED_IDENTIFIER"
| "UNEXPECTED_TOKEN"
| "UNEXPECTED_END"
| "EXPECTED_TOKEN"
| "INVALID_DICE_COUNT"
| "INVALID_DICE_SIDES"
| "DICE_LIMIT_EXCEEDED"
| "DIVISION_BY_ZERO"
| "MODULO_BY_ZERO"
| "INVALID_KEEP_DROP_COUNT"
| "INVALID_KEEP_DROP_TARGET"
| "EXPLODE_LIMIT_EXCEEDED"
| "INVALID_EXPLODE_TARGET"
| "REROLL_LIMIT_EXCEEDED"
| "INVALID_REROLL_TARGET"
| "INVALID_SUCCESS_COUNT_TARGET"
| "INVALID_SORT_TARGET"
| "INVALID_CRIT_THRESHOLD_TARGET"
| "INVALID_DIE_BOUND_TARGET"
| "INVALID_THRESHOLD"
| "NESTED_VERSUS"
| "INVALID_FUNCTION_ARITY"
| "UNDEFINED_VARIABLE"
| "AMBIGUOUS_DICE_CHAIN"
| "MAX_DEPTH_EXCEEDED"
| "NON_FINITE_RESULT"
| "INVALID_NOTATION_TYPE";
}
true when value is a roll-parser error the input caused
Type guard for the failures the input is answerable for: a roll-parser error whose
codeis one of NOTATION_ERROR_CODES. This is the test to hang a user-facing message on — isRollParserError only establishes origin, and answerstruefor a bad options object and a broken library invariant too, both of which should page you instead.Pair the two: the outer filter rethrows what is not ours, and this one splits what is left into "tell the user" and "report a bug".
Unlike isRollParserError, this one has to read the
codeagainst the list this build carries — attribution is not something a brand can express. So where the outer filter accepts a code it has never heard of, this one rejects it: an error from a newer minor carrying a notation code added after this build reads asfalseand is misfiled as internal. That is the safe direction — it pages a developer rather than blaming a user — but keep the library and its consumers on one version when the distinction drives more than a message.