Parsing invalid model data

[bikeshedder]

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?

[bikeshedder]

I decided not to implement this. (for the time being)

[bikeshedder]

Just as I was about to remove the FIXME comment from the code I realized that there is a middle ground. When parsing invalid model data I'll return an error but that error has a field that provides access to the data that could not be validated.

[bikeshedder]

After looking at the data my SolarEdge SE25K returns I realized that validating the data returned by SunSpec devices is a mistake. The devices tend to implement the spec incorrectly and with the approach I outlined yesterday one would always end up having to handle both the Ok case and Err case.

I ultimately decided against validating the data at all and just return the points as-is. In order to support invalid enum values I added an Invalid(Self::Repr) variant.

In the end this is the most ergonomic approach for real world applications, I think.