Re: [xml-dev] SAXException, checked, buy why?

[Jeff Rafter <lists@jeffrafter.com>]

> If you made your class abstract, then your content handler and 
 > application could agree on some shared way of exchanging
 > information (through a subclass known to both of them) that is
 > best suited to the problem at hand, without involving the API
 > too much.

Right, this seems like the best way to go. Or maybe I misunderstood the 
whole discussion... but let me get this straight:

(1) You have a whole mess of ContentHandlers lined up in a filter chain 
or chains
(2) You want to throw a non-SAX exception that may, or may not, stop all 
processing-- in some event callback
(3) You want to rewrite the API to manage all of this complexity

My first problem with this is that it would require parser authors to 
support your changes. The second is that I am not sure it solves the 
problem. The main problem is that of tunnelling exceptions through the 
API. So why use the API for this at all? Instead create a new 
ContentHandler that has built in exception management. There are a 
million ways to do this (please excuse the grotesque psuedo-code) :


public SafeContentHandler : ContentHandler

   public void startElement(...) throws SAXException {
     try {
      super(...)
     catch (Exception e) {
       if (!HandleException(e))
         throw e;
     }
   }

   public bool HandleException(Exception e) {
     return false;
   }
}

Something like this could be placed in your object heirarchy. One could 
also very easily create a tee-like observer pattern and some 
ExceptionHandler class. This could be designed into a subclass 
ContentHandler and used from within callbacks

public FooContentHandler : ContentHandler {

   public ExceptionHandler exceptionHandler;

   public void startElement(...) {
     // some code happens, we need to throw an exception
     exceptionHandler.Handle(new FooException());
   }
}

public ExceptionHandler {

   public void Handle(Exception e)
     throws SAXException {
     if (....) {

     } else
      throw new SAXException(e);
   }
}

Now these are just some random ideas thrown out after a long night in 
the rain so I could be way off. Also, in the back of my mind I am 
wondering about how Java handles that exception class if not actually 
thrown. On top of that I saw in some of your examples that you handled a 
FileNotFound exception in a slightly different way (it seems that IO 
exceptions would need a slightly different pattern anyway because they 
are not treated strictly as SAXParseExceptions to begin with). But all 
of leads me to think that you can have your cake and eat it too...

All the best,
Jeff Rafter