codeNames property

List<String> get codeNames

Canon's own name(s) for returnCode, or empty when canon defines none.

A reader who sees -7 has to go looking; canon calls it Z_EDESERIALIZE. The name is offered alongside the number in toString, never in place of it — a caller matching on a code, or pasting one into a search, still needs the integer.

Why a list, and not a name

⛔ Canon aliases one value. Z_EINVAL_MUTEX and Z_EPOISON_MUTEX are both -22. A map keyed by number cannot render that honestly by picking one, so this returns every name canon gives the value, in canon's declaration order. The collision becomes type-level instead of a silent choice, and the unnamed case falls out naturally as [].

What is deliberately absent

  • Binding-owned positive codes (10, 11, 12, 13) yield no name, because they are channel-scoped rather than global: 12 is the shim's allocation failure on the open channel and trailing data on the deserialize channel. A number-keyed global accessor structurally cannot render two meanings for one number, so it renders neither. ⚠️ That double meaning is ACCEPTED, not resolved — stated here because an accepted collision left silent reads as an oversight.
  • Canon's channel states. Z_CHANNEL_DISCONNECTED (1) and Z_CHANNEL_NODATA (2) are canon's, but they are states, not errors. ⛔ The != 0 convention this binding applies everywhere else must not be applied to the recv family, or an ordinary empty channel reads as a failure.
  • Per-code prose. Canon defines names, not meanings, so this offers no explanation of what a code implies. Where a path needs one it says so locally — see Session.open's rendering, which qualifies Z_ENETWORK as a catch-all because the symbol alone would read as a diagnosis canon never made.

Implementation

List<String> get codeNames => _canonErrorNames[returnCode] ?? const [];