[ 
https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512868
 ] 

Chris Schmidt commented on XMLRPC-143:
--------------------------------------

Isn't that essentially what this block of code is doing (unless this has 
already been patched, in which case I am sorry) -- from XmlRpcWriter.write() 

        if (pThrowable != null  &&  extensions  &&  (pConfig instanceof 
XmlRpcStreamRequestConfig)  &&
                ((XmlRpcStreamRequestConfig) pConfig).isEnabledForExceptions()) 
{
            try {
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                ObjectOutputStream oos = new ObjectOutputStream(baos);
                oos.writeObject(pThrowable);
                oos.close();
                baos.close();
                map.put("faultCause", baos.toByteArray());
            } catch (Throwable t) {
                // Ignore me
            }
        }

You should be able to deserialize the XmlRpcException from the response and get 
the linked exception to get at the root of the problem in the situation where 
the rpc request fails.

or am I just misunderstanding the request? 

> Rethrow the same exception thrown on the server side
> ----------------------------------------------------
>
>                 Key: XMLRPC-143
>                 URL: https://issues.apache.org/jira/browse/XMLRPC-143
>             Project: XML-RPC
>          Issue Type: New Feature
>          Components: Source
>            Reporter: Trejkaz
>
> If I have an object on the server which throws a custom exception, at present 
> the XML-RPC server code will create a generic XmlRpcException.
> Notably, this causes two problems for the caller.
> 1. Because all errors are thrown as XmlRpcException, it becomes impossible to 
> distinguish an error contacting the server, with an error thrown by the 
> application code.  In the former case, I would like to retry a couple more 
> times.  In the latter case, retrying is pointless and perhaps even harmful.
> 2. The stack trace is obliterated.  Ideally, the stack trace would be 
> serialised along with the rest of the exception and reconstructed on the 
> client side.
> As Throwable itself is Serializable and Apache XML-RPC already handles 
> Serializable objects elsewhere, this should not be a major headache.  I don't 
> mind if it requires extensions to be enabled as I'm already forced to enable 
> those to get support for returning null. :-)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to