StandardCode extension type

A framework-defined standard error code (SPEC.md §8.3).

Why an extension type and not an enum

A Dart enum would give exhaustive switches and would throw on a value it does not know. Error codes arrive from peers, and SPEC §5.2 requires a consumer to tolerate a newer MINOR — so a peer emitting a code added after this release would crash the parse rather than fall through to the §8.5 handling the spec prescribes. That is the wrong failure for a wire value.

An extension type over String is zero-cost, erases to String, keeps == and the named constants below, and represents an unrecognised code without complaint. This puts Dart alongside Rust's #[non_exhaustive] enum and Go's named string type. TypeScript's closed union is the odd one out, and adding a standard code is a breaking change only there.

Narrow a wire value with isStandardCode and keep a fallback branch:

final code = payload.code;
if (isStandardCode(code)) {
  // a §8.3 code, in canonical spelling
} else {
  // a §8.5 extended code
}

on

• String

Constructors

StandardCode(String value)

const

Properties

value → String

final

Constants

cancelled → const StandardCode

expired → const StandardCode

idConflict → const StandardCode

identityMismatch → const StandardCode

internalError → const StandardCode

malformedRequest → const StandardCode

permissionDenied → const StandardCode

proofInvalid → const StandardCode

proofRequired → const StandardCode

taskFailed → const StandardCode

unavailable → const StandardCode

unsupportedType → const StandardCode

unsupportedVersion → const StandardCode

values → const List<StandardCode>

Every §8.3 code, in the order SPEC.md declares them.

wrongRecipient → const StandardCode