Re: [Quickfix-developers] Re: empty tag

[Brian E. <azz...@ya...>]

Oren -

I'd definitely go with the NoTagValue exception method rather than
attempting to guess what the developer "really" wants.

You have the removeField method for the case of needing to strip a
field out of a message, so providing a backdoor way of doing that via
adding a "blank" value is redundant. It also isn't obvious that "blank"
= "delete".

Considering how many FIX engines choke on a missing tag value, I think
it's a good idea to default to not allowing it. I'd rather add a new
method (addBlankField or some such) or optional parameter (e.g.,
message.set(value, allowBlanks)) on the off chance that some weird FIX
implementation out there requires the existence of a tag even if there
is no value for it than allow what is normally considered "bad" FIX to
go out by default.

- Brian Erst
Thynk Software, Inc.

--- Oren Miller <or...@qu...> wrote:

> My concern is how to handle the situation where the field already
> exists.  If field 58 is set in the message, and I set it again with a
> field that has an empty tag, what does this mean?  Does it mean that
> I ignore the new field and retain the old value?  Or do I remove the
> old field from the message completely.  In which case setting a field
> with an empty tag is the same behavior as calling removeField.  Both
> of these behaviors feel a little surprising to me.  I'd be interested
> in hearing other opinions on this.
> 
> --oren
>   ----- Original Message ----- 
>   From: Alvin Wang 
>   To: Oren Miller 
>   Cc: qui...@li... ;
> qui...@li... 
>   Sent: Tuesday, July 05, 2005 9:40 PM
>   Subject: [Quickfix-developers] Re: empty tag
> 
> 
> 
>   Oren, I can understand where you are coming from. It makes total
> sense if QF throws NoTagValue exception in this case. However, I just
> feel it will add workload to the developers and the production may
> become disruptive. 
> 
>   Thanks 
>   Alvin 
> 
> 
> 
> 
>        "Oren Miller" <or...@qu...> 
>         07/05/2005 10:00 AM 
> 
>                
>                 To:       
> <qui...@li...>,
> <qui...@li...>, "Alvin Wang"
> <AW...@FF...> 
>                 cc:         
>                 bcc:         
>                 Subject:        Re: empty tag 
> 
> 
> 
>   We could, although more likely I would throw a NoTagValue
> exception.  I don't much like the idea of having QF silently ignoring
> a field that the developer would be expecting to go out in the
> message (much like I don't like the current behavior).  I can imagine
> the head scratching that would go on if they added a field and then
> found it mysteriously absent in the logs. 
>     
>   In either case if you have a field that might contain a blank
> value, I would suggest checking it before adding it to a message. 
>     
>   --oren 
>   ----- Original Message ----- 
>   From: Alvin Wang 
>   To: qui...@li... ;
> qui...@li... 
>   Cc: Oren Miller 
>   Sent: Tuesday, July 05, 2005 9:10 PM 
>   Subject: empty tag 
> 
> 
>   HI 
> 
>   If I set a tag as below: 
>   message.set(new Text(text)); 
>   and if the variable "text" is null. QF will include an empty tag
> 58. As a result, some FIX engine (such as QF itself) on the other end
> will reject the message.  Can QF skip including empty tag? 
> 
>   Thanks 
>   Alvin
>
**********************************************************************
> This e-mail message is intended solely for the use of the addressee.
> The message may contain information that is privileged and
> confidential. Disclosure to anyone other than the intended recipient
> is prohibited. If you are not the intended recipient, please do not
> disseminate, distribute or copy this communication, by e-mail or
> otherwise. Instead, please notify us immediately by return e-mail
> (including the original message with your reply) and then delete and
> discard all copies of the message. We have taken precautions to
> minimize the risk of transmitting software viruses but nevertheless
> advise you to carry out your own virus checks on any attachment to
> this message. We accept no liability for any loss or damage caused by
> software viruses.
>
**********************************************************************
> 
> 
>