Hi Vincent, On 8/10/07, Vincent Massol <vincent@massol.net> wrote:
On Aug 9, 2007, at 9:20 PM, Catalin Hritcu wrote:
[snip]
I checked and confluence does throw exceptions for all erroneous situations. Also all methods in swizzle-confluence (a client-side proxy for the confluence remote api) have a "throws Exception" clause. This means it makes a lot of sense to always throw an exception when something goes topsy-turvy on the server (now the behavior depends on mood of the writer of each method, and we don't check for many error conditions).
For exceptions to be sent back to the client we need to enable them on the server using the "enabledForExtensions" parameter (currently it's turned off).
But we can't do this, right. If we do we might break clients tools such as swizzle, unless they do a big catch of Exception or Throwable and treat them generically.
Yes, but this is more or less what they have to do now anyway (catch Exception). And swizzle does have a "throws Exception" on every method.
What exception gets out of XMLRPC on the client side? The typed exception sent on the server or some XMLRPC client side exception class?
This depends on many things. 1. If the server is not enabled for exceptions but an exception is thrown on the server then the client will try to throw a generic XmlRpcException saying that something went bad, but no reason is given. However, this works only if the method has a "throws XmlRpcException" clause (which is usually not the case). Otherwise the client will throw a runtime exception (UndeclaredThrowableException). This is what happens now. 2. If the server is enabled for exceptions then the client will try to re-throw the original exception. This is what I would like to have soon.
[snip]
This is true. The confluence API specifies boolean return types for some methods just because of bugs in some xml-rpc implementations. For example:
boolean logout(String token) - remove this token from the list of logged in tokens. Returns true if the user was logged out, false if they were not logged in in the first place (we don't really need this return, but void seems to kill XML-RPC for me)
Anyway, we should stick to what the API specification says, and sometimes that means returning meaningless booleans.
Fine with me *provided* we document this in our XMLRPC classes so that the next person that looks at it understand why there are 2 ways to return stuff...
Sure, I will do that. Regards, Catalin