[lxml-dev] parser target exception recovery bug?

[D.Hendriks (Dennis)]

Hello,

 > Yes. Should be fixed in SVN now:

Thanks.

 > I may have to look into this a bit closer, but so far, I don't see an
 > obligation to call it in the case of an error.

The lxml 2.2 documentation (pdf) states: "You can reuse the parser and 
its target as often as you like, so you should take care that the 
.close() methods really resets the target to a usable state (also in the 
case of an error!)." I assumed this meant that the close() method will 
always be called, even in case of errors, to (re)set the parser target 
into a usable state for the next parsing. Is this not true? If not, the 
next parsing operation will most likely fail, since the state of the 
parser target was not reset yet.

Dennis



Stefan Behnel wrote:
> Hi,
> 
> D.Hendriks (Dennis) wrote:
>> Using lxml 2.2 with a custom parser target (tree builder), I've run into 
>> a problem when the parser target raises an exception. In this case, 
>> parsing continues, although only for 'data' (not for 'start' and 'end').
>>
>> [nicely detailed example stripped]
>>
>> The first output (between --- and ---) is ok, since it is for the 
>> non-exception parser target. The second output (after the second ---) is 
>> not ok for me. You can see 'ERROR' at the point where the exception is 
>> raised. After that, two 'data' events are generated in the parser 
>> target. Clearly, parsing continued. Also, the 'close' is never called. 
>> After the entire input is parsed, the exception is finally re-raised.
>>
>> Two questions:
>>   - Is the continued parsing ('data' function calls) a bug?
> 
> Yes. Should be fixed in SVN now:
> 
> https://codespeak.net/viewvc/?view=rev&revision=65796
> 
>>   - Is the not calling 'close' a bug?
> 
> I don't know. ElementTree doesn't specify the behaviour in the error case.
> 
> http://effbot.org/elementtree/elementtree-xmlparser.htm
> 
> In my tests, ET 1.3 didn't call the .close() method either. I may have to
> look into this a bit closer, but so far, I don't see an obligation to call
> it in the case of an error.
> 
> Stefan
> 
> _______________________________________________
> lxml-dev mailing list
> lxml-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/lxml-dev