I see your point. I'm using xmlrpc-1.2.b-1 in my current live version
and it does throw XmlRpcExceptions like this:
org.apache.xmlrpc.XmlRpcException: Unable to complete the query.
So I've never had to worry about what execute() does because it always
seems to do it properly.
Which implies that the 2.0 final that Henry is using does something
else.
dga
>>> [EMAIL PROTECTED] 06/10/2005 10:44:37 AM >>>
Based on my experience w/ version 1.1, I believe Henry is correct in
expecting the fault to be thrown as an Exception. I quickly dug into
the
1.1 source and found this block of code following the processing of
execute:
if (fault)
{
// this is an XML-RPC-level problem, i.e. the server reported an
error.
// throw an XmlRpcException.
XmlRpcException exception = null;
try
{
Hashtable f = (Hashtable) result;
String faultString = (String) f.get ("faultString");
int faultCode = Integer.parseInt (
f.get ("faultCode").toString ());
exception = new XmlRpcException (faultCode,
faultString.trim ());
}
catch (Exception x)
{
throw new XmlRpcException (0, "Server returned an invalid fault
response.");
}
throw exception;
}
Michael
----- Original Message -----
From: "Henry Story" <[EMAIL PROTECTED]>
To: <[email protected]>
Cc: "Donald Albertson" <[EMAIL PROTECTED]>
Sent: Friday, June 10, 2005 8:29 AM
Subject: Re: rpcClient.execute returns a XMLRpcException
MMhhh? I don't have any trouble with execute returning an exception.
It just seems that it would
be more correct to throw it, so that I can catch the exception. That
is the whole point of
exception handling, no?
try {
Object resObj = rpcClient.execute(new XmlRpcRequest
("metaWeblog.newMediaObject", params));
Hashtable res = (Hashtable)resObj;
} catch (XmlRpcException e) {
//[1] do something here
} catch (IOException e) {
throw new TransferFilesException("IO problem trying to
communicate with server", e);
} catch (ClassCastException e) {
//[2]
}
Ie: In the above code it would seem more natural for the
XmlRpcException to be cought at
[1] than at [2], or to have a large switch statement inside the
initial try { } code.
What I am saying I just found is that resObject was a
XmlRpcException. Are you saying that
is right?
Henry
On 10 Jun 2005, at 15:55, Donald Albertson wrote:
>
> The server that my client accesses with execute() can return several
> valid results. It is up to me to parse them and see if they are
> valid.
> If the server returns an exception, I have to respond to it.
> So I'd say that the behavior is correct and the response you are
> getting has the information that you need to respond accordingly.
>
>
>
> Progress can not occur without the will to change that with which
you
> are currently comfortable.
>
