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.
