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:
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.
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:
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!


D.H.J. Takken schrieb am 05.12.2014 um 15:31:
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.
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:
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!

participants (2)
-
D.H.J. Takken
-
Stefan Behnel