etree.xmlfile shadows exceptions thrown by output
Hello,
I use etree.xmlfile and a coroutine to generate XML into a file-like object that does post-processing on the XML data. Now, if I use the send() method to produce invalid XML data, the post-processor throws an exception.
Here, I see a little problem: No matter what exception is thrown by the post-processor, the send() method always generates a generic IO exception. Apparently, lxml catches any exception thrown by the file-like object and produces a generic IO exception in stead. This means that there is no way to know what exactly went wrong in the post-processor. That information is lost.
Inside the coroutine, I *do* get the original exception from the post-processor, but doing the error handling there is kind of ugly.
Is there a better way to solve this problem?
Thanks a lot!
D.H.J. Takken schrieb am 05.12.2014 um 15:31:
I use etree.xmlfile and a coroutine to generate XML into a file-like object that does post-processing on the XML data. Now, if I use the send() method to produce invalid XML data, the post-processor throws an exception.
Here, I see a little problem: No matter what exception is thrown by the post-processor, the send() method always generates a generic IO exception. Apparently, lxml catches any exception thrown by the file-like object and produces a generic IO exception in stead. This means that there is no way to know what exactly went wrong in the post-processor. That information is lost.
Inside the coroutine, I *do* get the original exception from the post-processor, but doing the error handling there is kind of ugly.
Is there a better way to solve this problem?
Could you provide some example code that illustrates this, and mark the places where the exception is available and where it's lost?
Is it possible that the output stream is closed (or otherwise unwritable) when your post-processing exception is raised, so that an actual IOError is raised when trying to write out the closing tags, which then shadows the original exception?
I assume you're using Python 2.x, which cannot chain exceptions?
Stefan
On 12/05/2014 03:59 PM, Stefan Behnel wrote:
Could you provide some example code that illustrates this, and mark the places where the exception is available and where it's lost?
I will try to cook up a test case, may take some time.
Is it possible that the output stream is closed (or otherwise unwritable) when your post-processing exception is raised, so that an actual IOError is raised when trying to write out the closing tags, which then shadows the original exception?
I don't close the output stream when throwing the exception.
On closer inspection, the situation is slightly different than I just described: I do not know for sure if the exception is masked in the coroutine or not. Need to test. Presently, I solve the problem by catching the exception in the write method of the file-like object that lxml writes into. If I don't catch the exception there, allowing it to trickle downstream, I get an IOError in stead of the original exception.
Sorry for the confusion.
I assume you're using Python 2.x, which cannot chain exceptions?
Yes, this is on Python 2.x.
Thanks for your quick response!
On 12/05/2014 03:59 PM, Stefan Behnel wrote:
Could you provide some example code that illustrates this, and mark the places where the exception is available and where it's lost?
Is it possible that the output stream is closed (or otherwise unwritable) when your post-processing exception is raised, so that an actual IOError is raised when trying to write out the closing tags, which then shadows the original exception?
I assume you're using Python 2.x, which cannot chain exceptions?
Stefan
Hi,
I cooked up a testcase (attached), which illustrates the issue. It looks like lxml just eats any exceptions in the output, leaving the output in a broken state. Only if you try to write to that same output again, things explode.
Yes, this is Python 2.x.
Thanks again for looking into this!
On 01/03/2015 03:53 PM, D.H.J. Takken wrote:
Hi,
I cooked up a testcase (attached), which illustrates the issue. It looks like lxml just eats any exceptions in the output, leaving the output in a broken state. Only if you try to write to that same output again, things explode.
Yes, this is Python 2.x.
Thanks again for looking into this!
Should I file a bug report for this issue in the bug tracker?
D.H.J. Takken schrieb am 23.01.2015 um 11:53:
On 01/03/2015 03:53 PM, D.H.J. Takken wrote:
I cooked up a testcase (attached), which illustrates the issue. It looks like lxml just eats any exceptions in the output, leaving the output in a broken state. Only if you try to write to that same output again, things explode.
Yes, this is Python 2.x.
Thanks again for looking into this!
Should I file a bug report for this issue in the bug tracker?
Sorry for the long delay in answering. I'm rather packed with other stuff ATM, so please create a ticket and attach the test script to it to make sure it doesn't get lost. I'll try to look into it soon.
Stefan
On 01/27/2015 07:49 AM, Stefan Behnel wrote:
Sorry for the long delay in answering. I'm rather packed with other stuff ATM, so please create a ticket and attach the test script to it to make sure it doesn't get lost. I'll try to look into it soon.
participants (2)
-
D.H.J. Takken -
Stefan Behnel