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

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

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>lot's of details on error handling I haven't been following very
well</snip>

>    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.

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?

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...

   public XXException() {
       super();
       msgV = new Vector();
       highestLevel = DBG;
   }

   protected void addMsg( String msg, String type ) {
       msgV.add( type + " " + msg );     }

   public void addDbg( String msg )  {
       addMsg( msg, "dbg" );
   }

   public void addMsg( String msg )  {
       if ( highestLevel < MSG )
           highestLevel = MSG;
       addMsg( msg, "msg" );
   }

   public void addWng( String msg )  {
       if ( highestLevel < WNG )
           highestLevel = WNG;
       addMsg( msg, "wng" );
   }

   public void addErr( String msg )  {
       addMsg( msg, "err" );
       highestLevel = ERR;
   }

   public void test() throws XXException  {
       if ( highestLevel == ERR )
           throw this;
   }

   public void test( int level ) throws XXException {
       if ( msgV.size() > 0 && highestLevel >= level )
           throw this;
   }

   public String getMessage() { // For straight text messages 
       StringBuffer out = new StringBuffer();
       for ( int i = 0; i < msgV.size(); i++ )
           out.append( msgV.get( i ) + "\n" );
       return out.toString();
   }

  // Create aNodeSet
  public NodeSet getXmlMsg() throws
javax.xml.parsers.ParserConfigurationException {
...
            return new NodeSet( retNd );
   }

   // Create an SAX stream for the output messages
   public void generateSaxMsgs( XMLConsumer xmlConsumer, String
namespace, String prefix ) {
...
   }

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;

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;

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.

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>

-- 
Peter Hunsberger