Hi Asiri, On 8/10/07, Asiri Rathnayake <[email protected]> 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).
I think we should also throw the generic java.lang.Exception type exceptions along with some error code and a meaningful error message and avoid XWiki specific exceptions (i think it's obvious).
I agree on this not only for the reason you mention, but also because I find the exception mechanism in XWiki very cumbersome. It seems that having to write 3 lines of code to throw an exception causes many to just not throw them at all. But sure, the primary reason for going with standard Java exceptions in the XML-RPC implementation would be interoperability. What do the others think? Are there good reasons for using XWikiException here? [snip]
Please name the methods which caused you trouble and I'll look into it.
Well, everything mentioned in XMLRPC API with a void return type will cause a problem. But I think i have replaced the only one such method (delete page, i think) currently implemented in XWiki. Anyway, as we go on implementing more of the API, we'll need to have a boolean (or something suitable) as the return type for those conflicting methods in API.
Asiri, if the interface says void then i would stick to void, the same way we should stick with boolean when the interface says so. I will look into other ways to fix these problems (i.e. ways that don't involve changing the API) and come back to you. Regards, Catalin