views:

99

answers:

2

My app writes a lot of XML data, and randomly the last line of the following piece of code:

// Prepare the DOM document for writing
Source source = new DOMSource(node);

// Prepare the output stream
Result result = new StreamResult(stream);

// Write the DOM document to the file
Transformer xformer = TransformerFactory.newInstance().newTransformer();
xformer.transform(source, result);

..throws..

javax.xml.transform.TransformerException: java.io.IOException: Detected invalid substitute UTF-16: da89 4f ?

(additionally, I don't know why, but this exception is the only one raised by the vm in my language, Portuguese, as "Detectado substituto UTF-16 inválido", I've translated it to "Detected invalid UTF-16 substitute")

Another strange thing is that I'm using UTF-8, not UTF-16, in my texts, I've checked it. And, I believe if the UTF was the problem, it would not cause randomly exception, as I'm getting the same amount of text to transform to XML.

This exception is difficult to reproduce, as it does not occur always, and it occurs when transforming lots of data to XML.

Any idea what is happening here?

A: 

Construct your source from an input stream, not a reader, and let the XML parser figure out the character set.

EJP
I'm not sure if I understand, I updated my source code in the question. As you can see, I'm constructing the source using DMOSource(Node). If you mean the text source file, it is being contructed using an input stream.
Tom Brito
A: 

The workaround I could think is make the program re-excute the action when it fails. As it is difficult to reproduce, it should never occur twice in a row.

Tom Brito
Have you been logging all the times when it fails? If not, you should setup a logger to log when it fails and what the xml data looks like that it fails on. You can then compare that to the working ones.
xil3
@xil3 good point. For me, as I was using the same input, looks like there is no difference, but yours may be a good idea.. there must be any difference somewhere.. Anyway, I'm no more working on that project.. so it stays with this workaround as solution.
Tom Brito