[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Seeking SAXException pattern

• To: List <xml-dev@l...>
• Subject: Re: Seeking SAXException pattern
• From: Bill de hÓra <bill.dehora@p...>
• Date: Tue, 30 Nov 2004 11:32:32 +0000
• Cc: Gregory Murphy <Gregory.Murphy@e...>, Tim Bray <tbray@t...>
• In-reply-to: <Pine.GSO.4.10.10411291433560.23877-100000@gris>
• References: <Pine.GSO.4.10.10411291433560.23877-100000@gris>
• User-agent: Mozilla Thunderbird 0.9 (Windows/20041103)

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.

Yep; I think Tim's problem is a problem with checked exceptions rather 
than SAX [1].  The idiom I use to work around this problem, is to trap a 
checked exception and throw a runtime exception.

     import java.io.PrintStream;
     import java.io.PrintWriter;

     public class WrappedException
       extends RuntimeException
     {
       public static RuntimeException raise( Throwable t )
       {
         if(t instanceof RuntimeException)
           return (RuntimeException) t;
         else
           return new WrappedException(t);
       }

       Throwable itsThrowable;

       public WrappedException( Throwable t )
       {
         super();
         itsThrowable = t;
       }

       public String toString()
       {
         return getMessage();
       }

       public String getMessage()
       {
         return itsThrowable.getMessage();
       }

       public void printStackTrace()
       {
         itsThrowable.printStackTrace();
       }

       public void printStackTrace( PrintStream out )
       {
         itsThrowable.printStackTrace(out);
       }

       public void printStackTrace( PrintWriter out )
       {
         itsThrowable.printStackTrace(out);
       }

       public Throwable getWrapped()
       {
         return itsThrowable;
       }
     }


Not pretty but handles most of my needs.  So, I wind up with code like this:

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

• References:
  • Re: Seeking SAXException pattern
    • From: Gregory Murphy <Gregory.Murphy@e...>

• Prev by Date: Re: Relax-NG schema design question
• Next by Date: Re: Relax-NG schema design question
• Previous by thread: Re: Seeking SAXException pattern
• Next by thread: Is an XQuery Document an XML Document?
• Index(es):
  • Date
  • Thread