email article printer friendly get the code

Handling SAX Errors
Putting tests into your code can help ensure you are handling unexpected errors in an expected way
by James W. Cooper

November 2002 Issue

You're charging away using some great piece of code you wrote (or someone else wrote) that is making your life easier, when suddenly plotz! boom! The whole thing collapses in some useless Java error you don't understand and don't want to track down. Why do people write code like that? Because handling errors is a lot of trouble and it is much easier to leave them "as an exercise for the reader."

In his book about extreme programming, Kent Beck emphasizes that you should write tests for each method before you write the method. Good idea—too bad no one thought of that when they wrote the SAX parser (this is kind of tricky to do after the fact). You have to handle the inevitable errors that arise from incorrect XML. Unfortunately, with the SAX parser, error recovery is necessarily limited.

SAX Redux
You can write a simple SAX parser handler to find small documents in a large file of concatenated documents (see "Practicing Safer SAX," October 2002). To summarize, we decided that it would be more efficient to process a stream of short documents in a single file than to do all the I/O necessary to open and close each of the files in a large collection. So we created a simple XML file format where we used XML tags to represent the documents and their titles:

<coll>
   <seqment>
      <title PMID="xxxx">
         title of doc 1
      </title>
      text of document 1
   </segment>

   <seqment>
      <title PMID="yyyy">
         title of doc 2
      </title>
      text of document 2
   </segment>
</coll>