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

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

* Karl Waclawek <karl@waclawek.net> [2005-01-03 12:21]:
> Alan Gutierrez wrote:
> 
> >>>  http://www.saxproject.org/apidoc/org/xml/sax/ErrorHandler.html

> >    What if the type of error is not a SAXParseException? I'm
> >    already feeling uncomfortable calling everything a SAXException.

> Yes, but that is the trouble with checked exceptions.
> Personally I think it would have been better to pass an object
> of some non-exception type to the error handler call-backs.
> The class could have been named SAXError, or SAXStatus.

> Actually, in SAX for .NET we have decided to pass a non-ecxeption
> class to the error handlers, but we are still calling it ParseError
> - so maybe we should rename it to SAXError, to be more generic.

    Naming is important.
    
    Thanks for this message. This is, for me, a very productive
    discussion.

    What you're saying, is that in .NET, you didn't bother with an
    exception. This is in line with my thinking.
    
    I'd like to treat the SAXError as a container and structure that
    contains the necessary information to recover from the
    exceptional situation. That it is also an Error, means that
    there's a ready object for throwing, one with a correct strack
    trace.

> Well - in our western society - what is not explicitly forbidden, is 
> allowed. :-)

    Sweet liberty.

> As an example for another possible approach, one could have
> defined all handlers to accept a "Status" object as additional
> parameter (based on some abstract class definition).  Each handler
> in the chain could inspect and modify this object, allowing
> information to pass up and down.  The application could register a
> concrete subclass instance of that Status class with the event
> generator, to provide for custom processing of errors.

    I am working with a bevy resuable handlers that I reuse through
    object composition. In any SAX content handler in a content
    handler chain, I've got dozens of objects decorating and
    delegating.
    
    Its not one monolithic SAX content handler, but a composition of
    SAX strategies.

    I'd planned on using the event handler below, as described.

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

    The SAXError, although it will be an unchecked exception class,
    will also provide context information.
    
    It will be like the status object in your .NET API. There will
    be an added benfit of being something that the error handler can
    throw if things don't work out.

    public class BarFooCassandara {
        public void error(SAXError saxError) {
            try {

                throw error.getCause();

            } catch (FileNotFoundException e) {

                // Perhaps providing parse state is overexposure.

                // I've wondered why FileNotFoundException didn't
                // have a getFile() method since that would be what
                // we need here.

                String fileName = error.getElement() // (Not really SAX.)
                                       .getAttributes()
                                       .getValue("file-name");

                if (!BarFileUtils.touch(new File(fileName))) {
                    // Throw SAXError since it's unchecked.
                    throw saxError;
                }

                // Otherwise, we are fine. Work with touched file.
            } catch (FooResourceError e) {
                if (!FooManager.freeUpSomeFoos()) {

                    // Wrap this in an exception type that the
                    // process initiator expects to catch.

                    throw new BarFooError(e);
                }
            } catch (Throwable e) {
                // If the contianed exception is unchecked, throw
                // that, otherwise, throw the saxError.
                throw saxError.asUnchecked();
            }
        }
    }

    The SAXError class now looks like:

    public final class SAXError extends Error {
        public SAXError(Throwable cause) {
            super("Error in SAX.", cause);
        }

        public Element  getElement() { }
        public Object   getErrorObject() { }    // This.
        public Map      getErrorInfo() { }      // Even more Perlish.
    }

    The class in final because a SAX error is really just a wrapper
    for a real, application error. No message either. That is found
    in the real cause. Eh?

    I've decided to forgo checked exceptions. (I've had my
    awakening.) I'll have that debate with anyone, if they'd like,
    so's to learn something. I know its a common an trollish debate,
    so I've avoided it in the past. I will gladly read any
    references on the state of that debate.

    I am hoping I don't sound to confident, I'd still like to know
    what's wrong with my thinking. There must be something.

    Cheers.
    
--
Alan Gutierrez - alan@engrm.com