You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What should happen if parsing of a point fails? What about non-spec compliant devices? As of now you just can't interact with those devices using the read_model function. It will just return an Err(ReadModelError::DecodeError(_)).
I quite like the idea of returning the not fully validated model as part of the ReadModelError. It makes it painfully obvious that something went wrong but still provides access to the structurally parsed data.
Alternatively a second set of models could be generated where everything is Optional and validation doesn't happen at all. This could even ignore errors such as models which are too short, etc.
I was also thinking of wrapping all points in a PointValue<T> structure that implements Deref<Target=T> making it possible to add an extra error: Option<PointError> field to every value. This will double the memory usage and require users to sprinkle a lot of * in the code for manual dereferencing which can panic if used with the non-validated variant of that struct.
I don't even know if this is an issue to begin with. Are there any real-world devices that need to be supported that implement the spec horribly wrong? Should this even be supported by this crate?
The text was updated successfully, but these errors were encountered:
What should happen if parsing of a point fails? What about non-spec compliant devices? As of now you just can't interact with those devices using the
read_model
function. It will just return anErr(ReadModelError::DecodeError(_))
.I quite like the idea of returning the not fully validated model as part of the
ReadModelError
. It makes it painfully obvious that something went wrong but still provides access to the structurally parsed data.Alternatively a second set of models could be generated where everything is Optional and validation doesn't happen at all. This could even ignore errors such as models which are too short, etc.
I was also thinking of wrapping all points in a
PointValue<T>
structure that implementsDeref<Target=T>
making it possible to add an extraerror: Option<PointError>
field to every value. This will double the memory usage and require users to sprinkle a lot of*
in the code for manual dereferencing which can panic if used with the non-validated variant of that struct.I don't even know if this is an issue to begin with. Are there any real-world devices that need to be supported that implement the spec horribly wrong? Should this even be supported by this crate?
The text was updated successfully, but these errors were encountered: