[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAXException, checked, buy why?


sax getattributes
* Karl Waclawek <karl@w...> [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@e...

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.