{{Quickfixn}} Missing tags, tag order; symbol tag 55

[Manuel Lopez]

Ola,
Thank you for the clarification.  Offhand that seems like undesirable
behavior to me, but I'd need to know what the fix 4.4 protocol expects
for handling intended null values (versus unintended, only seeming
"nulls," that would be the result of error).  To clarify, I assumed
(what would seem desirable) that when **the quickFIX definition file**
has required="N" then no error will be thrown by quickfix if the field
is missing, since the field is NOT required, so NOT an error not to
send it.  (And I can take a null without an error or use null coalesce
operator, and null means no value or not applicable.)  But it seems
that what you're saying is that even merely looking at a tag for a
null, and even at a field quickfix knows is optional, will trigger an
exception.  So that seems like unusual behavior--the usual behavior I
think would be to just allow null without error for a missing value,
as null is a meaningful value, but instead I need to wrap a
msg.IsSetField check everywhere.  I can see the thinking though, that
receiving a field with no or null value is different from not
receiving a field at all, but in the case of fix I think that's not
so, since I assume every tag that gets sent must have a value, to the
right of the equal sign (even if "NONE"), and that not passing an
optional field is like a null (although for required fields I assume
fix would require sending "NULL" for nulls or disallow nulls for
required fields).
At any rate, I guess the upshot is adding a lot of IsSetField lines to my code.
Manuel

"but on the other hand when they set the Required="N" meaning they can
send it or not depending on some condition on their side, then its
mandatory for you to check if it's set before getting the field.
Take for example if your counter party defines Tag 58 as optional for
the ExecutionReport (35=8)  and only sets it if your NewOrderSingle
(35=D) was rejected with the reason for rejection, If you try to get
that field when it's not set, your FIX engine would assume the message
your received is incomplete as a field you require is not set, thereby
rejecting the message, hence why you should always check Non-Required
fields before trying to get them."