Fix for reading optional fields in final structs, we now expect their emHeaders
Fix for reading absent optional fields at the end of a message that would cause a RangeError
Docs
Description
Fixes two issues in our implementation of optional fields.
The first issue (FG-8644) was us not expecting optional parameters of final structs to have emHeaders in XCDR1.
This is specified in the spec here:
This was fixed by adding && field.isOptional.
The second issue (FG-8627) fixed occurred in PL_CDR2 when trying to read the absent, optional, final field of a message, which was causing a RangeError because emHeaders are not present for absent optional fields in PL_CDR2 since they are able to check id's of the emHeaders. This was fixed by catching the RangeError and returning undefined as we do when the emHeader is not the id we expect which is the other case when optional field is not present.
I also wrapped the readMemberFieldValue in a try/catch to be able to give better error messages at which field failed and where in the serialized message it encountered the error.
Changelog
Docs
Description
Fixes two issues in our implementation of optional fields.
The first issue (FG-8644) was us not expecting optional parameters of final structs to have emHeaders in XCDR1. This is specified in the spec here:
This was fixed by adding
&& field.isOptional.The second issue (FG-8627) fixed occurred in PL_CDR2 when trying to read the absent, optional, final field of a message, which was causing a RangeError because emHeaders are not present for absent optional fields in PL_CDR2 since they are able to check id's of the emHeaders. This was fixed by catching the
RangeErrorand returningundefinedas we do when the emHeader is not the id we expect which is the other case when optional field is not present.I also wrapped the
readMemberFieldValuein atry/catchto be able to give better error messages at which field failed and where in the serialized message it encountered the error.