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

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

* Karl Waclawek <karl@waclawek.net> [2005-01-03 09:11]:
> 
> 
> Alan Gutierrez wrote:
> 
> >>It may be Java-oriented because I don't understand the problem.
> >>Speaking for the Python case, since you don't have to declare
> >>exceptions, the handler can throw anything it pleases, which, if not
> >>handled by the driver falls to the original parse-calling code.
> >
> >
> >    I'm not Python-oriented, so I might be making hash of this
> >    response, but I think this is a generic concern.
> >
> >    Assume no checked exceptions. That is some Java hand-wringing
> >    that I'll discuss with Java developers if they are interested.
> >    
> >    <java-specific-musing boring-for="Uche">
> <snip>
> >    </java-specific-musing>
> >        
> >    How do you provide the fellow who invokes the event conduit with
> >    a means to intercept exceptions at the event handler?
> >    
> >    Say I've a content handler that likes to open files. The action
> >    to take when a file is not found could be to skip it an move on,
> >    or it could be that the file can be fabricated real quick, or it
> >    could be that processing has to abort via an exception.
> >    
> >    This is an application descision. How does the application
> >    developer configure the content handler so that the exceptional
> >    condition is handled during the event?
> 
> I am not sure I understand this question, as the answer I am thinking
> of is trivial:

> A SAX event handler can handle exceptions thrown by the calls it makes.
> Or it can let them escape. Depends on whether it wants to "notify"
> the event generator or not. How is that not possible in Java?

    It is not possible if the exception is checked exception. You
    have to wrap in in SAXException, or in an unchecked exception to
    let it rise through the SAX filter chain.

    Then it's game over. The 499 of 500 GB you processed? Toast.
    
> Apart from the above, consider the case of a chain of content
> handlers (a "pipeline"). If one link in the chain throws an
> exception, the links that are "downstream" get no notification at
> all (if they are even called) as one does not "bubble" exceptions
> down. Each of the downstream handlers might throw another
> exception.

    My cunumdrum.

> Maybe in that case event handlers should avoid throwing
> exceptions at all, and rather notify an error handler.

    Agreed.
    
    Please consider my idea again.

    Assume at the SAX content handler author, and the SAX
    application author are two different entities. That the SAX
    content handler cannot anticipate how exceptions should be
    handled.

    What is the design of an API for exception handling within the
    content handler? Within the observer of an observer pattern?

    I proposed on in an earlier message:

    public interface SAXCassandra {
        public void error (SAXError saxError);
    }

    By implementing this observer, and handing it off to a content
    handler, the application developer can inspect errors before they
    are thrown.

    The sax filter author writes:

    public void startElement(
        String ns, String ln, String qn, Attributes as
    ) {
      if (ln.equals("foo")) {
        FileInputStream in = null;
        String fileName = as.getValue("file-name");
        do {
          try {
            in = new FileInputStream(new File(fileName));
          } catch (FileNotFoundException e) {
            this.cassandra.error(new SAXError(e));
          }
        } while (in == null);
      }
    }

    The above probably wouldn't give the application author enough
    information to recover from the error, but we can fix that by
    creating a special SAXError, or wrapping a Foo specific
    exception that includes the file name.

--
Alan Gutierrez - alan@engrm.com