There is a solution if you use XFire in the client API sense (code
first, identical domain classes on server and client). I created a
generic exception class which wraps message and class name of any
runtime exception, e.g.
... catch (RuntimeException r)
{
throw new GenericRuntimeExceptionWrapper(r);
}
whereas GenericRuntimeExceptionWrapper is a checked exception and must
extend XFireException. In this way the runtime exception's message and
class name are transported to the client, and Java XFire clients can
recreate and throw the runtime exception. Non Java clients see at least
the runtime exception's message and class name.
I was able to hide all of this in autogenerated code (a layer on top of
XFire), runtime exception handling is completely transparent on the
server and the client.
Werner
On 28.09.2007 20:00, Hogan, Gavin wrote:
I think this is a problem with runtime exceptions are not caught by the
handlers, exceptions such as NullPointer and NumberFormat. I too am
looking for a way to catch, and handle these exceptions. Any ideas
would be welcome.
Gavin
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
