10 Aug
2007
10 Aug
'07
8:52 a.m.
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.
What exception gets out of XMLRPC on the client side? The typed
exception sent on the server or some XMLRPC client side exception class?
[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...
[snip]
Thanks Catalin for looking into this
-Vincent