fault code is always zero

[Benjamin Reed <be...@motricity.com>]

I'm implementing an XML-RPC server, and it appears there is no way to 
override the fault code returned on an error.

There are any number of ways to patch org.apache.xmlrpc.XmlRpcException 
to do it, but I'd rather not if I can avoid it.

It seems like the only way to do so ties my exceptions to 
XmlRpcException (by needing to extend it), which would make it hard to 
expose other interfaces to the same codebase.

Perhaps it would be possible to have the fault-code handling code check 
for a method "getCode" in the exception, and if it exists, use that?

Re: fault code is always zero

[Adam Taft <ad...@hydroblaster.com>]

In the javadocs for XmlRpcException, it specifically states, "For 
servers based on this library, this [the fault code] will always be 0. 
(If there are predefined error codes, they should be in the XML-RPC spec.)"

So, for common XmlRpc errors (like, improperly formatted requests, 
etc.), you'll always get an error code of 0.  However, that doesn't mean 
that you can't define your own custom error codes for your application. 
  The constructor for XmlRpcException includes a fault code.  Most of 
the errors I need to pass back to my client tend to be application 
errors, not XmlRpc transport errors.  So, this works just fine for me.

The point is, there's no specification as to how common XmlRpc errors 
should be handled, which fault code they should produce, etc.  The best 
spec I have found for this is 
http://xmlrpc-epi.sourceforge.net/specs/rfc.fault_codes.php though I 
don't think these have been officially adopted or anything.

I wonder if the xmlrpc maintainers/devs are interested in adopting this 
proposed standard.  Might be a nice thing to do.

Hope this helps.


Benjamin Reed wrote:
> I'm implementing an XML-RPC server, and it appears there is no way to 
> override the fault code returned on an error.
> 
> There are any number of ways to patch org.apache.xmlrpc.XmlRpcException 
> to do it, but I'd rather not if I can avoid it.
> 
> It seems like the only way to do so ties my exceptions to 
> XmlRpcException (by needing to extend it), which would make it hard to 
> expose other interfaces to the same codebase.
> 
> Perhaps it would be possible to have the fault-code handling code check 
> for a method "getCode" in the exception, and if it exists, use that?