[
https://issues.apache.org/jira/browse/XMLRPC-143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514021
]
Trejkaz commented on XMLRPC-143:
--------------------------------
Interesting utility class. I have one exactly like it from back when this
project didn't (it looks almost exactly like mine, but I bet the type convertor
is better.). I should move over to it so that I can delete my own one.
Though it doesn't help for 3.0 because a 3.0 server won't pass the exception
along anyway. XmlRpcStreamRequestConfig in that version only had the
gzipCompressing property.
> 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.
