Gestion des erreurs avec un parser non-validant

This version of the Echo program uses the nonvalidating parser. So it can't tell if the XML document contains the right tags, or if those tags are in the right sequence. In other words, it can't tell you if the document is valid. It can, however, tell whether or not the document is well-formed.

In this section of the tutorial, you'll modify the slideshow file to generate different kinds of errors and see how the parser handles them. You'll also find out which error conditions are ignored, by default, and see how to handle them.

Introducing an Error

The parser can generate one of three kinds of errors: fatal error, error, and warning. In this exercise, you'll make a simple modification to the XML file to introduce a fatal error. Then you'll see how it's handled in the Echo app.
Note: The XML structure you'll create in this exercise is in slideSampleBad1.xml. The output is in Echo05-Bad1.log.
One easy way to introduce a fatal error is to remove the final "/" from the empty item element to create a tag that does not have a corresponding end tag. That constitutes a fatal error, because all XML documents must, by definition, be well formed. Do the following:
    Copy slideSample.xml to badSample.xml.
  1. Edit badSample.xml and remove the character shown below:
    2.  ...
<!-- OVERVIEW -->
<slide type="all">
  <title>Overview</title>
  <item>Why <em>WonderWidgets</em> are great</item>
  <item/>
  <item>Who <em>buys</em> WonderWidgets</item>
</slide>
 ...
    to produce: 
     ...
<item>Why <em>WonderWidgets</em> are great</item>
<item>
<item>Who <em>buys</em> WonderWidgets</item>   
 ...
  2. Run the Echo program on the new file.
The output you get now looks like this: 
...
        ELEMENT: <item>
        CHARS:   The 
            ELEMENT: <em>
            CHARS:   Only
            END_ELM: </em>
        CHARS:    Section
        END_ELM: </item>
    CHARS:   
    END_ELM: 
CHARS:   org.xml.sax.SAXParseException: Expected "</item>" 
         to terminate element starting on line 20.
at com.sun.xml.parser.Parser.fatal(Parser.java:2800)
at com.sun.xml.parser.Parser.fatal(Parser.java:2794)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1406)
at com.sun.xml.parser.Parser.content(Parser.java:1499)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
at com.sun.xml.parser.Parser.content(Parser.java:1499)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
at com.sun.xml.parser.Parser.parse(Parser.java:284)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:168)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:104)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:131)
at Echo05.main(Echo05.java:59)
When a fatal error occurs, the parser is unable to continue. So, if the application does not generate an exception (which you'll see how to do a moment), then the default error-event handler generates one. The stack trace is generated by the Throwable exception handler in your main method: 
  ...
} catch (Throwable t) {
    t.printStackTrace ();
}
That stack trace is not too useful, though. Next, you'll see how to generate better diagnostics when an error occurs.

Handling a SAXParseException

When the error was encountered, the parser generated a SAXParseException -- a subclass of SAXException that identifies the file and location where the error occurred.
Note: The code you'll create in this exercise is in Echo06.java. The output is in Echo06-Bad1.log.
Add the code highlighted below to generate a better diagnostic message when the exception occurs: 
  ...
} catch (SAXParseException spe) {
   // Error generated by the parser
   System.out.println ("\n** Parsing error" 
      + ", line " + spe.getLineNumber ()
      + ", uri " + spe.getSystemId ());
   System.out.println("   " + spe.getMessage() );

} catch (Throwable t) {
    t.printStackTrace ();
}
Running the program now generates an error message which is a bit more helpful, like this: 
** Parsing error, line 22, uri file:<path>/slideSampleBad1.xml
   Next character must be...
Note:
Catching all throwables like this is not a good idea for production applications. We're just doing it now so we can build up to full error handling gradually.

Handling a SAXException

A more general SAXException instance may sometimes be generated by the parser, but it more frequently occurs when an error originates in one of application's event handling methods. For example, the signature of the startDocument method in the DocumentHandler interface is defined as returning a SAXException: 
public void startDocument () throws SAXException
All of the DocumentHandler methods (except for setDocumentLocator) have that signature declaration.

A SAXException can be constructed using a message, another exception, or both. So, for example, when Echo.startDocument outputs a string using the emit method, any I/O exception that occurs is wrapped in a SAXException and sent back to the parser: 

private void emit (String s)
throws SAXException
{
    try {
        out.write (s);
        out.flush ();
    } catch (IOException e) {
        throw new SAXException ("I/O error", e);
    }
}
Note: If you saved the Locator object when setDocumentLocator was invoked, you could use it to generate a SAXParseException, identifying the document and location, instead of generating a SAXException.
When the parser delivers the exception back to the code that invoked the parser, it makes sense to use the original exception to generate the stack trace. Add the code highlighted below to do that: 
 ...
} catch (SAXParseException err) {
    System.out.println ("** Parsing error" 
        + ", line " + err.getLineNumber ()
        + ", uri " + err.getSystemId ());
    System.out.println("   " + err.getMessage ());

} catch (SAXException sxe) {
    // Error generated by this application
    // (or a parser-initialization error)
    Exception  x = sxe;
    if (sxe.getException() != null)
        x = sxe.getException();
    x.printStackTrace();

} catch (Throwable t) {
    t.printStackTrace ();
}
This code tests to see if the SAXException is wrapping another exception. If so, it generates a stack trace originating from where that exception occurred to make it easier to pinpoint the code responsible for the error. If the exception contains only a message, the code prints the stack trace starting from the location where the exception was generated.

Improving the SAXParseException Handler

Since the SAXParseException can also wrap another exception, add the code highlighted below to use it for the stack trace: 
  ...
} catch (SAXParseException err) {
     System.out.println ("** Parsing error" 
        + ", line " + err.getLineNumber ()
        + ", uri " + err.getSystemId ());
     System.out.println("   " + err.getMessage ());

     // Unpack the delivered exception to get the exception it contains
     Exception  x = spe;
       if (spe.getException() != null)
           x = spe.getException();
       x.printStackTrace();

} catch (SAXException e) {
    // Error generated by this application
    // (or a parser-initialization error)
    Exception   x = e;
    if (e.getException () != null)
        x = e.getException ();
    x.printStackTrace ();

} catch (Throwable t) {
    t.printStackTrace ();
}      
The program is now ready to handle any SAX parsing exceptions it sees. You've seen that the parser generates exceptions for fatal errors. But for nonfatal errors and warnings, exceptions are never generated by the default error handler, and no messages are displayed. Next, you'll learn more about errors and warnings and find out how to supply an error handler to process them.

Handling a ParserConfigurationException

Finally, recall that the SAXParserFactory class could throw an exception if it were for unable to create a parser. Such an error might occur if the factory could not find the class needed to create the parser (class not found error), was not permitted to access it (illegal access exception), or could not instantiate it (instantiation error).

Add the code highlighted below to handle such errors: 

} catch (SAXException e) {
    Exception   x = e;
    if (e.getException () != null)
        x = e.getException ();
    x.printStackTrace ();

} catch (ParserConfigurationException pce) {
    // Parser with specified options can't be built
    pce.printStackTrace();

} catch (Throwable t) {
    t.printStackTrace ();
This code, like the SAXException handler, takes into account the possibility that the reported exception might be wrapping another exception. (Admittedly, there are quite a few error handlers here. But at least now you know the kinds of exceptions that can occur.)
Note:
A javax.xml.parsers.FactoryConfigurationError could also be thrown if the factory class specified by the system property cannot be found or instantiated. That is a non-trappable error, since the program is not expected to be able to recover from it.

Handling an IOException

Finally, while we're at it, let's stop intercepting all Throwable objects and catch the only remaining exceptions there is to catch, IOExceptions: 
} catch (ParserConfigurationException pce) {
    // Parser with specified options can't be built
    pce.printStackTrace();

} catch (Throwable t) {
    t.printStackTrace ();
} catch (IOException ioe) {
    // I/O error
    ioe.printStackTrace();
}

Understanding NonFatal Errors

In general, a nonfatal error occurs when an XML document fails a validity constraint. If the parser finds that the document is not valid (which means that it contains an invalid tag or a tag in location that is disallowed), then an error event is generated. In general, then, errors are generated by the ValidatingParser, given a DTD that tells it which tags are valid. There is one kind of error, though, that is generated by the nonvalidating parser you have been working with so far. You'll experiment with that error next.
Note: The file you'll create in this exercise is slideSampleBad2.xml. The output is in Echo06-Bad2.log.
The SAX specification requires an error event to be generated if the XML document uses a version of XML that the parser does not support. To generate such an error, make the changes shown below to alter your XML file so it specifies version="1.2". 
<?xml version='1.02' encoding='us-ascii'?>
Now run your version of the Echo program on that file. What happens? (See below for the answer.)
Answer: Nothing happens! By default, the error is ignored. The output from the Echo program looks the same as if version="1.0" had been properly specified. To do something else, you need to supply your own error handler. You'll do that next.

Handling Nonfatal Errors

A standard treatment for "nonfatal" errors is to treat them as if they were fatal. After all, if a validation error occurs in a document you are processing, you probably don't want to continue processing it. In this exercise, you'll do exactly that.
Note: The code for the program you'll create in this exercise is in Echo07.java. The output is in Echo07-Bad2.log.
To take over error handling, you override the HandlerBase methods that handle fatal errors, nonfatal errors, and warnings as part of the ErrorHandler interface. The SAX parser delivers a SAXParseException to each of these methods, so generating an exception when an error occurs is as simple as throwing it back.

Add the code highlighted below to override the handlers for errors: 

public void processingInstruction (String target, String data)
throws SAXException
{
  nl();
  emit ("PROCESS: ");
  emit ("<?"+target+" "+data+"?>");
}

// treat validation errors as fatal
public void error (SAXParseException e)
throws SAXParseException
{
  throw e;
}
Now when you run your app on the file with the faulty version number, you get an exception, as shown here (but slightly reformatted for readability): 
START DOCUMENT
<?xml version='1.0' encoding='UTF-8'?>
   ** Parsing error, line 1, uri file:/<path>/slideSampleBad2.xml
   XML version "1.0" is recognized, but not "1.2".
org.xml.sax.SAXParseException: XML version "1.0" is recognized, but not "1.2".
at com.sun.xml.parser.Parser.error(Parser.java:2778)
at com.sun.xml.parser.Parser.readVersion(Parser.java:1052)
at com.sun.xml.parser.Parser.maybeXmlDecl(Parser.java:984)
at com.sun.xml.parser.Parser.parseInternal(Parser.java:478)
at com.sun.xml.parser.Parser.parse(Parser.java:284)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:168)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:104)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:131)
at Echo07.main(Echo07.java:59)
Note: The error actually occurs after the startDocument event has been generated. The document header that the program "echoes" is the one it creates on the assumption that everything is ok, rather than the one that is actually in the file.

Handling Warnings

Warnings, too, are ignored by default. Warnings are informative, and require a DTD. For example, if an element is defined twice in a DTD, a warning is generated -- it's not illegal, and it doesn't cause problems, but it's something you might like to know about since it might not have been intentional.

Add the code highlighted below to generate a message when a warning occurs: 

// treat validation errors as fatal
public void error (SAXParseException e)
throws SAXParseException
{
  throw e;
}

// dump warnings too
public void warning (SAXParseException err)
throws SAXParseException
{
  System.out.println ("** Warning"
      + ", line " + err.getLineNumber ()
      + ", uri " + err.getSystemId ());
  System.out.println("   " + err.getMessage ());
}
Since there is no good way to generate a warning without a DTD, you won't be seeing any just yet. But when one does occur, you're ready!
Note: By default, HandlerBase throws an exception when a fatal error occurs. You could override the fatalError method to throw a different exception, if you like. But if your code doesn't, the reference implementation's SAX parser will.