Re: [xml-dev] Seeking SAXException pattern

[Alan Gutierrez <alan-xml-dev@engrm.com>]

* Bill de hÓra <bill.dehora@propylon.com> [2004-11-30 06:33]:
> Gregory Murphy wrote:
> >On Sat, 27 Nov 2004, Tim Bray wrote:
> >
> >
> >>I'm writing some java code that uses a basic SAX parser, and I haven't 
> >>done this for years if ever, and the callback routines all have 
> >>signatures that throw SAXExceptions, e.g.
> >>
> >>  public void characters(char [] s, int start, int length)
> >>    throws SAXException
> >>
> >>So, suppose I'm in this callback and something horrible happens; for 
> >>example I discover that the content that I'm looking at here is 
> >>completely bogus.
> >
> >
> >The wrapped-exception pattern is a pretty common solution to the visibility
> >problem posed by call-back APIs. The call-back code is in your class, but
> >when a problem arises, your method is sitting on top of somebody else's
> >method in the call stack. So you need some way of "tunneling" your
> >exception through.

>    try
>    {
>      myValidationCode(s, start, length);
>    }
>    catch (SAXException e)
>    {
>      throw WrappedException.raise(e);
>    }
> 
> You can subclass that and trap if you need fine graining or domain 
> specific exceptions. As a runtime exception, any caller that doesn't 
> want to deal with it doesn't have to. It also avoids trapping other 
> runtime exceptions that you don't want to be dealing with in the guts of 
> your code. [I think Bob Lee gets the credit for being the first person 
> to publicly document it.]
> 
> 
> Btw, this:
> 
>    try
>    {
>      myValidationCode(s, start, length);
>    }
>    catch (Exception e)
>    {
>      throw new SAXException(e);
>    }
> 
> is not always a good idea (and not just for SAX).
> 
> cheers
> Bill
> 
> [1] Background reading:
> http://www.mindview.net/Etc/Discussions/CheckedExceptions
> 
> (I'm not sure checked exceptions won't just become extinct eventually.)

    They are difficult to deal with.

    I've taken to creating error reporting interfaces, and allowing
    clients to throw the unchecked exception of their choosing.

    public interface Cassandra {
        public void classNotFound(String className, ClassNotFound e);

        public void security(Method method,
                             Object[] parameters,
                             InvocationException e);

        public void invocation(Method method,
                               Object[] parameters,
                               InvocationException e);
    }

    Something like the above is used to propigate reflection errors,
    but allows a client to specify the Exception thrown by providing
    an implementation.

    So, I guess I'm suggesting, you can use the ErrorHandler to
    unify all exceptions thrown to an unchecked exception of your
    choosing, but you'd still have to catch the checked SAXException.

    Bother.

--
Alan Gutierrez - alan@engrm.com