[
Lists Home |
Date Index |
Thread Index
]
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.)
|