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
At the moment if you have a missing value for a field in an Artio decoder after a decode then:
(1) if the field is required then validation will fail and a missing sentinel value like: MISSING_FLOAT will be returned from the accessor.
(2) if the field is optional then validation will pass and an exception like new IllegalArgumentException("No value for optional field: OrderQty"); will be thrown by the accessor.
There is a proposal to change the behaviour of (2) so that instead of throwing an exception it would return the MISSING sentinel value. Validation would still object to a missing required field but not a missing optional field as that's what optional means.
This has the advantage of simplifying codec usage by making behaviour more consistent and simplifying generation by removing some special casing. It is a change of behaviour that's subtle in the sense of not breaking an API. I'd like to solicit feedback as to whether anyone has strong objections to this change or you're ok with it?
The text was updated successfully, but these errors were encountered:
At the moment if you have a missing value for a field in an Artio decoder after a decode then:
(1) if the field is required then validation will fail and a missing sentinel value like:
MISSING_FLOAT
will be returned from the accessor.(2) if the field is optional then validation will pass and an exception like
new IllegalArgumentException("No value for optional field: OrderQty");
will be thrown by the accessor.There is a proposal to change the behaviour of (2) so that instead of throwing an exception it would return the MISSING sentinel value. Validation would still object to a missing required field but not a missing optional field as that's what optional means.
This has the advantage of simplifying codec usage by making behaviour more consistent and simplifying generation by removing some special casing. It is a change of behaviour that's subtle in the sense of not breaking an API. I'd like to solicit feedback as to whether anyone has strong objections to this change or you're ok with it?
The text was updated successfully, but these errors were encountered: