OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

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

[ Lists Home | Date Index | Thread Index ]

* Karl Waclawek <karl@waclawek.net> [2005-01-04 19:30]:
> 
> 
> Alan Gutierrez wrote:
> 
> >    If the sender and receiver agree on a class, then they can put
> >    it in variables map attached to the StrategyError.
> 
> What about behaviour?

    Thanks. Yes.
    
 ~A On data.
 
    I think this is something of a common problem with frameworks.
    It feels counter intuitive to say that the signature for an
    event is as simple as.

    public interface Event {
        public int getType();
        public Object getData();
    }

    But, what more can the conduit designer know about a particular
    event? Especially something as generic as an "error" event.

    It seems silly, to me, to have an interface like so:

    public interface ErrorData {
    }

    public interface Error {
        public ErrorData getErrorData();
    }

    This is a common problem I see arrising in frameworks. You want
    to be extensiable, so you have to forgo some typing, or else use
    reflection, which also forgos typing.

    That's why I suggested a map. It seems like after I've worked
    with this error handler long enough, I'd know what sort of
    typing to add and how.

  ? What processing specific data is available.

    What other data occurs in an error? Do I want to provide a path?
    A smidge of overhead, and already part of my system. But, if
    from another SAX filter, that path might not have a real
    document to reference. 

    Document location. Again, might not exist, since these might
    only be events. Imagine a SAX handler that simply watches a socket.
    Still, good candidate.

    For SAX Strategy, my library, the current strategy, and the
    current event (because I create event objects to encasualte
    event data).

 ~B On behavior.

    That's hard. What behavior is common to all error handling?
    
    I'd like to know, really, because I'd like to take some time to
    develop some error handling best practices, and perhaps, and
    error event library is a project in itself.

    Uche, in a other thread, broke down handling, as pass, fail,
    log, or fix. For pass, fail/raise, and log, one can probably
    provide default implmentations, and dispatch them based on
    pattern matching.
    
    This exception class, raised by this handler, log and fail.

    Oh, I guess, with an interface as simple as this.

    public interface StrategyCassandra {
        public void error(StrategyError strategyError);
    }

    At some point I was expecting to see the fixes written out in
    the error method, so the interface name is now a misnomer.

    The object will not always be a Cassandra.

    public interface ErrorResponder {
        public void error(Event event, StrategyError error);
    }

    Then you get this implementation, which oddly takes the place of
    a catch block.

    public class ErrorDispatcher implements ErrorResponder {
        public void forError(ErrorResponder response);
        public void forError(Class exceptionType, ErrorRepsonder response);
        public void forErrors(Class[] exceptionTypes, ErrorRepsonder response);
    }
 
    The error method could return boolean, and that is checked to
    see if the error was handled. Or maybe the StrategyError has a
    retry method.

    public void parseFooXML throws SAXException {
        ErrorDispatcher dispatch = new ErrorDispatcher();

        dispatch.forError(FileNotFoundException.class, new ErrorResponder() {
            public void error(Event event, StrategyError error) {
                String fileName = event.getElement()
                                       .getAttributes()
                                       .getValue("file-name");
                if (!creatyPlaceHolderFooXML(fileName)) {
                    throw strategyError;
                } else {
                    strategyError.retry();
                }
            }
        });

        dispatch.forError(FooResourceException.class, new ErrorResponder() {
            public void error(Event event, StrategyError error) {
                throw BarFooResourceError();
            }
        });

        XMLReader reader = new XMLReaderFactory.createXMLReader();
        EventSink eventSink = new StrategyChain()
                                  .strategy(new FooStrategy())
                                  .newEventSink(dispatch);
        reader.setContentHandler(eventSink);

        boolean processed = false;
        do {
            try {
                reader.parse(new InputSource(new FileInputStream("foo.xml"));
                processed = true;
            } catch (FooBarResourceException e) {
                if (!FooResourceManager.freeUpSomeFoos()) {
                    throw e.getCause();
                }
            }
        } while (!processed);
    }

    Better?

--
Alan Gutierrez - alan@engrm.com




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS