RE: [HAPI-devel] RE: new feature (making the PipeParser able to r ecover from errors)

[Tripp, B. <Bry...@uh...>]

Hi Alexei, 
 
Lots of good points!  Always a pleasure.  

 incurring into the risk of introducing errors. Keep in mind that the
validation code will still be respected by the recovery handler (when the
setValue method is called from within it) meaning that the user won't be
able to assign arbitrary values to the parsed component. And I very much
think that introducing this sort of feature early, will  

I'm not worried about that at all ... I just want to minimize the number of
places in which message content can be changed.  Right now we have one (i.e.
explicit calls on the message object).  

 

 (and I'd like to emphasize that this is a core feature of all parsers,
error recovery).  

My understanding of error recovery in language parsers is that they only
exist so that additional errors can be correctly identified (e.g. so you can
produce a whole list of compile errors rather than just one).  Correct me if
I'm wrong about this.  What you are proposing allows passing erroneous input
by changing it in some way.  To me this seems analogous to a Java parser
that finds !+ and decides what was probably meant was !=, and then compiles,
setting a flag somewhere that the code was changed.  That's the part I was
objecting to anyway -- if I've misunderstood please let me know.  

 

In the long term, error recovery would be great, but I think it should only
be used to create a complete list of problems that can be returned to the
sending system in the rejection message. 

 

In the short term, I agree that we do need a way to work around the problem
you identified, and your proposal will certainly do it. 

 we   should include it as soon as we can, maybe right after the 0.4
release, in some sort of 0.4.1 version .. bla bla bla ;) 

Perfect, let's come back to this right after the 0.4 release.  

 

Bryan 

 



This e-mail may contain confidential and/or privileged information
for the sole use of the intended recipient. Any review or distribution
by anyone other than the person for whom it was originally intended is
strictly
prohibited. If you have received this e-mail in error, please contact the
sender and
delete all copies. Opinions, conclusions or other information contained in
this e-mail may not be that of the organization.