small patch submission

[davebrown]

Hello all,

Attached please find a proposed patch to SaveToZipFile.java. Previously, when saving a document
and an error arises in JAXB marshalling, a stack trace is printed to stderr, but the exception is
swallowed. The result was half-formed XML in one of the document parts, with no error reported
to the calling code. With the patch, the exception is propagated up the call stack.

This patch is submitted in accordance with the docx4j contributor policy as described here:
http://dev.plutext.org/docx4j/docx4j_In ... butor.docx

I stumbled over this (admittedly, through my own error) by adding non-JAXB-serializable objects
to the top level list of the MainDocumentPart's Body element.

As an aside, let me say that I have been using docx4j over the last month on a new product, and I'm
impressed and thankful for how much docx4j does. My product involves diffing and merging, so I'm
eager to try the new com.plutext.merge.DocumentBuilder merge utility.

Dave Brown

P.S. - I'm including the patch inline, below. ".patch", ".diff", and ".txt" are disallowed as file
extensions for attachments by the forum software. What should I use for a patch extension?


-------------- dont-swallow-exception.patch --------------------
Index: src/main/java/org/docx4j/openpackaging/io/SaveToZipFile.java
===================================================================
--- src/main/java/org/docx4j/openpackaging/io/SaveToZipFile.java (revision 1319)
+++ src/main/java/org/docx4j/openpackaging/io/SaveToZipFile.java (working copy)
@@ -202,10 +202,10 @@
// Complete the entry
out.closeEntry();
log.info( "PUT SUCCESS: " + zipEntryName);
-
- } catch (Exception e) {
- // TODO Auto-generated catch block
- e.printStackTrace();
+ } catch (RuntimeException re) {
+ throw re;
+ } catch (Exception e) {
+ throw new Docx4JException("could not marshal " + part.getPartName(), e);
}

} else if (part instanceof org.docx4j.openpackaging.parts.CustomXmlDataStoragePart) {

[jason]

Attached please find a proposed patch to SaveToZipFile.java. Previously, when saving a document
and an error arises in JAXB marshalling, a stack trace is printed to stderr, but the exception is
swallowed. The result was half-formed XML in one of the document parts, with no error reported
to the calling code. With the patch, the exception is propagated up the call stack.

Thanks for this.

As an aside, let me say that I have been using docx4j over the last month on a new product, and I'm
impressed and thankful for how much docx4j does.

Thanks for this as well I've just added your remark and other testimonials floating right at http://dev.plutext.org/trac/docx4j/wiki/WikiStart

My product involves diffing and merging, so I'm
eager to try the new com.plutext.merge.DocumentBuilder merge utility.

Cool. Since that's commercial, pls feel free to email me off list to discuss.

Re diffing, I take it you've seen the com.topologi.diffx stuff in the src/diffx directory.

P.S. - I'm including the patch inline, below. ".patch", ".diff", and ".txt" are disallowed as file
extensions for attachments by the forum software. What should I use for a patch extension?

Yeah sorry about that; phpBB doesn't let me configure attachment types. so for a small patch, pasting it inline is fine; otherwise zip it up (which you also need to do to attach a docx, unfortunately)