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

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

On Wed, 5 Jan 2005 15:19:25 -0500, Alan Gutierrez
<alan-xml-dev@engrm.com> wrote:
> * Peter Hunsberger <peter.hunsberger@gmail.com> [2005-01-05 10:27]:
> > On Tue, 4 Jan 2005 22:45:22 -0500, Alan Gutierrez
> > <alan-xml-dev@engrm.com> wrote:
> > > * Karl Waclawek <karl@waclawek.net> [2005-01-04 19:30]:
> > > >
> > > >
> > > > Alan Gutierrez wrote:

<snip>earlier discussion</snip>

> >
> > I wish I had time to take in everything you've been bouncing back and
> > forth here.  It's a little unusual for xml-dev but it appears to apply
> > to much of what we are doing.  The reason why I'm commenting here is
> > that the above caught my eye and -- without really understanding the
> > whole issue -- suggests that you might have a inversion of control
> > (IOC) pattern that often shows up in frameworks?
> 
>    Yup. Yup.
> 
>    Thanks for reminding me. I'd forgotten about all that IOC
>    reading I'd done earlier in this year.
> 
>    I helps the discussion. Talking about it in terms of IoC might
>    cut through the, "Well, are your excpetions checked, or
>    unchecked?  Because unchecked exceptions are bad." stage of an
>    error handling disucssion.
> 
>    I'm finding that many Java programmers have an exceptoin
>    strategy that goes like so:
> 
>        1) Declare checked exception.
>        2) ?
>        3) Profit!
> 
>    Not on this list, but elsewhere.
> 
> > 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 {
> >    public final int DBG = -1;
> >    public final int MSG = 0;
> >    public final int WNG = 2;
> >    public final int ERR = 3;
> >    private int highestLevel = DBG;
> >    private Vector msgV = null;    // Map could be cleaner but more work...
> > 
>    [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...

> 
> >    }
> >
> >    // Create an SAX stream for the output messages
> >    public void generateSaxMsgs( XMLConsumer xmlConsumer, String
> > namespace, String prefix ) {
> 
>    Are you indicating here, that one option is to stream the error
>    report to the next handler? That's common in what I'm doing.
> 
>    Clever.

Yes, but also turning the exception into a regular data object that
can be passed around.  A Composition pattern can be used to wrap the
various data objects with object specific versions of a generic
interface, eg: something that builds a SAX stream or whatever.

> 
> >    }
> 
> > The things here that I suspect might be relevant to your discussion are:
> 
> > 1) you can pass one of these beasts around as an accumulator, the
> > game's not over on the first error. In particular, the vector wouldn't
> > have to be straight Strings;
> 
>    I keep a stack of "state of procesing" objects in a SAX
>    Content/LexicalHandler.
> 
>    The Content/LexicalHandler is a Fascade to a Composition of
>    event processing Strategies which Decorate and Delegate.
> 
>    (Strategies can hand off control to other strategies, for a
>        any sub-tree. A Strategy could hand off a sub-tree to
>        document builder Strategy. The document is returned to the
>        delegating Strategy when when the endElement event occurs.
> 
>        Hence the stack.)
> 
>    This state of processing object is where I'd put two chains of
>    objects.
> 
>        ~ ErrorResponder
>            - This is called to allow client code the opporuntiy to
>              respond to an exceptional condition before it is
>              thrown and processing is aborted. The error responder
>              can ignore, raise, suspend processing, log, or fix for
>              retry. (Suspend processing means to ignore the events
>              until we return a place were we can continue.)
> 
>        ~ ThrowResponder
>            - These are registered by participents withing the
>              SAX Content/LexicalHandler to restore state if an
>              event is thrown.
> 
>        ! IoC exception handling.

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 feel that the chaining and accumulation, can be done through
>    composition of the ErrorRepsonder interface. Which is:
> 
>    public interface ErrorResponder {
>        public void error(Context context, Event event, StrategyError error)
>        throws SomeSortOfException {
>        }
>    }
> 
>    You can have a DispatchingErrorResponder, or an ErrorResponderList,
>    and so on.

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?

> > 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.
> 
>        /* Image the method bodies, please. Flip any one breaker,
>         * and the other breakers raise and IllegalStateException(). */
> 
>    public final class StrategyError extends (Runtime)?Exception {
>        public StrategyError(Throwable cause) {
>            super(cause);
>        }
> 
>        /* Breaker. */
>        public void retry();
>        public boolean shouldRetry();
> 
>        /* Breaker, ignore events until we've gone up the ancestor
>         * axis for a specified index. */
>        public void unwind(int depth);
>        public boolean shouldUnwind();
> 
>        public int getUnwindDepth()();
> 
>        /* Breaker. */
>        public void pass();
>        public void shouldPass();
> 
>        /* For your responder catch ladder. */
>        public Throwable getCause();
> 
>        /* Perlish, but whadya gonna do? */
>        public Map notes();
> 
>        /* Something I do, so I can create an initialize within
>         * method parameters. */
>        public StrategyError note(Object key, Object value);
>    }

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.

> > 3) it knows the details of how to represent itself as a SAX stream or
> > a DOM or a String or whatever you might need: in your case that might
> > be some form of event wrapper.
> 
>    This is also new. I'm not thinking it through, but I think this
>    would be logic in a responder. One could create a generic
>    responder that does this. The responder gets a reference to the
>    next SAX handler through the processing context object.

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?

> > Then again, I may have missed the whole point of what you're talking
> > about.  If so, feel free to ignore completely...
> 
> > <snip>more complicated details</snip>
> 
>    Sorry about the details, I hope they don't discourage your
>    participation in this discussion.

Still confused, but what else is new?: continue to feel free to ignore
if I'm talking too much about things already discussed....

-- 
Peter Hunsberger