Re: SAX IoC Errors (Was: SAXException, checked, buy why?)

[Peter Hunsberger <peter.hunsberger@gmail.com>]

On Thu, 6 Jan 2005 12:08:10 -0500, Alan Gutierrez
<alan-xml-dev@engrm.com> wrote:

Hi Alan, not much time, I'll be out until next Wed.  Please excuse the
random un-annotated snips.

<snip/> 
> 
> > > > If so, I'm guessing, you might explore using the Exception or Error
> > > > itself to encapsulate much of the details on how to handle itself.  In
> > > > our case we do something like:
> > >
> > > > public class XXException extends Exception {
> 
> > >    [snip]
> > >
> > > >    public void test( int level ) throws XXException {
> > > >        if ( msgV.size() > 0 && highestLevel >= level )
> > > >            throw this;
> > > >    }
> > >
> > >    [snip]
> > >
> > >    Interesting. A severity flag.
> 
> > Doesn't have to be severity, you could add more formal types...
> 
>    The exception tests itself? Contains the throw decisions?

Anything you want.  I use a Vector of parsed strings, but might be be
a Map of objects (Maps).  Conceivably you could bubble up a whole
stream of events or partially processed items: a Map of things to
retry, a Map of things that where ignored, whatever.

<snip/>

> 
> > Hmm, maybe you should just treat the exceptions like any other
> > Strategy?  Don't even distinguish between them except for someway to
> > "test" them?  That seems more-or-less what you're doing but you seem
> > to have two interfaces where I'd have one...
> 
>    I have two, because the first interface cares about the error,
>    it's type, it's contents, the second only cares that an error
>    occured. The first is error handling, the second is cleanup.

That's the issue, you're still treating the Error itself as a special
case.  As you note latter, I'm thinking maybe it's just a case of a
Strategy (or maybe something else).

> 
> > Yes, but why add the extra interface?  Why not just re-use the same
> > interfaces you already have and implement them in the error objects?
> > If no error happens you get back the normal objects and they produce
> > they normal SAX stream, otherwise you get back an error object and it
> > produces the error SAX stream unless you care to "test" it in which
> > case it bubbles up the problems to to whom ever the "tester"
> > (Responder?) is?
> 
>    Are you thinking that I ought to use the Strategy interface? Or
>    are you talking about my idea to have two error interfaces?

The former, StrategyError extends Strategy.  It add's methods for
testing and moving things around that need retrying or whatever you
want to do, but in general you can just pop it up and down your stack
like anything else.
 
> > > > 2) it knows how to test itself for certain situations, you can have
> > > > additional methods for other situations and the details of what to do
> > > > for each case might be built in;
> > >
> > >    That's hard. I'd like to provide an object like the one you
> > >    described, but I would make it final, and spare. I'd compose
> > >    error handling logic using the responders.
> 
> > Not sure I see the need for the extra level of complexity, but then
> > again, I haven't been following closely...  The overall idea seems
> > similar to what I'd do.
> 
>    This thing above, the StrategyError (SAXError) with the
>    breakers, is supposed to provide complexity if needed.
> 
>    At one level, it's a bucket. It is also an exception wrapper if
>    an unchecked exception is needed. It is also provides some
>    obvious flags to control the shuffling around of the error as event.

Right, I'm saying the same thing, just that I'd add the extra
capabilities as wrapper capabilities around the normal processing
objects, which in this case I understand to be instances of Strategy
classes...

> 
> > Perhaps, I tend to end up with Interfaces wrapping Interfaces for
> > cases where I want to extend generic code with really special case
> > code.  That sometimes leads to "instanceof" type if/else blocks but
> > mostly polymorphism handles the whole thing cleanly and I don't have
> > to distinguish between "retry", "pass", etc. except for the
> > polymorphic versions of the methods.  In particular, a polymorphic
> > constructor or initializer on your Responder (I think) might handle
> > Strategy vs. ErrorStrategy in such cases?
> 
>    Oh, you seem to think that Strategy and ErrorStrategy ought to
>    be the same thing. Right?
> 
>    Here's Strategy as it stands:
> 
>    public interface Strategy {
>        void launched(Campaign campaign, Event event);
>        void startElement(Campaign campaign, Event event);
>        void characters(Campaign campaign, Event event);
>        void processingInstruction(Campaign campaign, Event event);
>        void skippedEntity(Campaign campaign, Event event);
>        void comment(Campaign campaign, Event event);
>        void endElement(Campaign campaign, Event event, Campaign concluded);
>        void concluding(Campaign campaign, Event event);
>    }
> 
>    What you've suggested, in a number of ways, is the idea that
>    errors flow forward to the next SAX handler. I'm not there yet.
> 
>    I'm still trying to figure out how a SAX handler, composed of
>    Strategies, handles it's own errors. How do errors flow back to
>    the head of the SAX chain?
> 
>    In this discussion, I saw my Strategy stack as an event conduit
>    in itself.
> 

It appears that wrapping this would do what I think you want to do. 
StrategyError  adds the special case handling to Strategy as needed. 
The portions of the code that care about errors can check for
instanceof  (or better use polymorphic methods) on the handling of
Strategy.

However, again, I'm rushed and I don't have time to really figure it
out, I may be way off base, sorry...

-- 
Peter Hunsberger