Consider raising errors for all messages with error bit set #56

Activity

1. glopesdev commented on Sep 26, 2026

   

   glopesdev

   on Sep 26, 2026

   Last edited by glopesdev

   Contributor

   More actions

   @bruno-f-cruz note the non-raising mode is currently broken, so today neither mode is a well-defined way to observe a rejected write.

   Device.write ends with an unconditional decode:

   msg = self._request(register.address, MessageType.Write, frame)
   return msg.decode(register)

   _request handles the error flag correctly, raising DeviceError only when raise_on_error is set and returning the reply otherwise. Then msg.decode(register) runs regardless. An error reply carries an empty payload, so decoding it against the register raises HarpParseError instead. Device.read does the same thing.

   That contradicts the DeviceError docstring, which states that constructing the device with raise_on_error=False gives such a reply "as an ordinary return value instead".

   This is already being hit as a limitation in downstream projects. The VertiGate hardware test opens the device with raise_on_error=False and carries a stand-in class so a parse failure on a reply can be read as a rejection.

   Why it matters for the decision here. A conformance test asserting that a write must be refused needs exactly one documented way to observe the refusal, and "writing X must be rejected" is a common pattern in the specification. If this resolves toward every error-bit message raising, then raise_on_error either goes away or has to keep its contract, and the decode ordering above becomes moot. If both modes survive, decode should check has_error before decoding. Either is fine; what does not work is the current state, where the documented alternative raises a parse error.