10 Aug
2007
10 Aug
'07
9:55 a.m.
Hi Asiri,
On 8/10/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
[snip]
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]
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
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).
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.