Expand description
One error type, two granularities.
§Why two
The Python client made this split by accident and it turned out to be
load-bearing. errors.py has a class per status the daemon deliberately
chooses — Conflict, NotFound, ProtocolError — and cli.py’s exit table
collapses all three onto one code, ERR_PROTOCOL, because a shell branching on
$? cannot usefully tell them apart and a caller who needs to has a message.
Both are contracts, to different consumers, and neither can stand in for the
other. The conformance suite asserts on the exception class
(conformance/run.py’s raises() takes Unauthorized, Conflict,
NotFound, ProtocolError), so a Rust client that only knew the coarse code
would make the oracle unable to tell a 400 from a 404 — and that distinction is
the one the daemon’s whole status discipline exists to preserve. So
Error::kind answers the exit-code question and Error::wire_kind answers
the which-status-did-the-daemon-choose question, and the CLI carries the second
into its JSON envelope as data.kind so the oracle keeps its granularity.
§What a caller matches on
ErrorKind, nearly always. WireKind exists for the two consumers that
need the finer view: the conformance driver, and a caller retrying a specific
daemon condition. Nobody should parse a message.
Structs§
- Error
- A failure, classified once at the point it is raised.