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

[Alan Gutierrez <alan-xml-dev@engrm.com>]

* Jeff Rafter <lists@jeffrafter.com> [2005-01-04 00:06]:
> >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

    Actually, I have a whole mess of ContentHandler like objects
    assembled as a composition in a single ContentHandler. 

    I am also doing a bit of pipelineing as well.

> (2) You want to throw a non-SAX exception that may, or may not,
>   stop all processing-- in some event callback

    I want to prevent an exception from being thrown if the
    situation is recoverable, hence the callback. 

> (3) You want to rewrite the API to manage all of this complexity

    Me? No. I'm using the SAX API. I've filled it in with something
    that allow for the composition of ContentHandlers from exsiting
    classes.

> 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) :

    Yes. I've implemented in terms of content handlers. No need to
    reimplement parsers. SAX is an excellent API design, really.

> 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...

    I'm using FileNotFoundException because it's recoverable in my
    examples. I'm not trying to make a point about I/O. It sticks
    out because it's my example of a situation recoverable during
    processing. In the case of a missing foo file, copy over a dummy
    foo file, and continue processing.

    You are correct in that a missing foo file is not an
    SAXParseException either. Both Karl and myself are discussing
    recoverable error events in processing, not so much parsing.

    Yes. We are working on having and eating cake.

    I'm starting to think that the observer pattern is a better way
    to /handle/ errors than exceptions. There is a distinction
    between throwing the exception, recovering state, and handling,
    which may include the options pass, raise, log, or fix.

    Okay. Here's the exmaple again. Using my API.

    public interface StrategyCassandra {
        public void error(
            Campaign campaign, Event event, StrategyError strategyError
        ) throws SAXException ;
    }

    public class FooStrategy extends IgnoreStrategy {
      private final Foo foo = new Foo();
      public void launched(Campaign campaign, Event event)
      throws SAXException {
        String fileName = event.getElement()
                               .getAttributes()
                               .getValue("file-name");
        FileInputStream in = null;
        do {
          try {
            in = new FileInputStream(new File(fileName));
          } catch (FileNotFoundException e) {
            campaign.error(new StrategyError(e));
          }
        } while (in == null);

        try {
          foo.forbnicate(in);
        } catch (FooException e) {
          campaign.error(new StrategyError(e));
        }
      }
    }

    Are there other ways to get the stack trace right? It would be
    nice if the stack trace ended in the reporting even handler.

    public class BarFooCassandra {
      public void error(
         Campaign campaign, Event event, StrategyError error
      ) throws SAXException {
        try {

          throw error.getCause();

        } catch (FileNotFoundException e) {

          String xpattern = "ancestor-or-self::foo[@file-name]";
          String fileName = event.getElement(xpattern)
                                 .getAttributes()
                                 .getValue("file-name");

          if (!BarFileUtils.copyPlaceHolderFooXML(fileName)) {
            throw strategyError;
          }

        } catch (FooResourceException e) {
          throw new BarFooResourceException(e);
        } catch (Throwable e) {
          strategyError.raise();
        }
      }
    }

    Called with.

    public void parseFoo() throws SAXException {
      EventSink eventSink = new SrategyChain()
                                .strategy(new FooSrategy())
                                .newEventSink();

      XMLReader reader = XMLReaderFactory.createXMLReader();
      reader.setContentHandler(eventSink);
      boolean processed = false;
      do {
        try {
          reader.parse(new InputSource(new FileInputStream("foo.xml"));
        } catch (BarFooResourceException e) {
          FooResourceManager.freeUpSomeFoos();
        } 
      } while (!processed);
    }

--
Alan Gutierrez - alan@engrm.com