ws-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rogers, Mike" <>
Subject RE: Purpose of Faults
Date Tue, 09 Jul 2002 12:42:00 GMT

Your observation about how the fault is returned is correct.

A "fault" is used to return an error that happened during the execution of
the function. This error could occur during the transmission and decoding of
the RPC call (ie. "Method not found", or a connection refused error.

A fault could also be used to raise an error during the method's execution.
I believe any type of execption thrown by a server side method will be sent
back as a fault, and can be processed on the client side. I am not sure
where the XmlRpcClient.execute function will actually thrown an exception to
be caught. If not, I would think it should since you would like your client
side code to operate the same as it would with a local call.

I personally would use XmlRpcException to handle error on the
transmission/encoding/decoding layer, and throw normal exceptions from
within your functions. After all, the beauty of XmlRpc is that you can use
any previous code behind it. You wouldn't want that code to be dependent on
the XmlRpcException and thus on the whole library. Your code should sit
freestanding behind the XmlRpc library.


> ----------
> From: 	Chris Kay
> Reply To:
> Sent: 	Tuesday, July 9, 2002 12:08 AM
> To:
> Subject: 	Purpose of Faults
> Hi all,
> I have a few questions regarding fault responses. I am using the Java
> implementation of XML-RPC where, when an XmlRpcException is thrown in one
> of
> the handlers, the XmlRpcServer will catch it and respond to the client
> with
> a fault response. Now my expectation was that the XmlRpcClient would
> distinguish a fault response from a non-fault response and thus throw an
> XmlRpcException itself on the client-side when a fault response is
> received.
> That, however, is not the case. The fault response is returned to the
> client
> as if it were a regular response and it is upon the client to identify the
> fault struct and not interpret it as a regular response. Is this proper
> behavior?
> When I discovered this fact I started to seriously wonder whether "users"
> of
> the XML-RPC implementation are actually expected at all to make use of
> fault
> responses (by throwing XmlRpcExceptions in their registered handlers) or
> whether it is actually meant for use by the implementation's code only
> (i.e.
> to signal server-specific faults that aren't low-level enough to warrant
> not
> sending a "200 OK" HTTP response).
> To give an example, assume there is a server that handles user
> authentication by matching a username and password that will be sent from
> a
> client. If the username and password can be matched the server should
> respond with a generated session key. If however the password is wrong or
> the username is unknown for instance, how should this be signaled to the
> client? My approach was to throw an XmlRpcException in the respective
> handler in such a case containing a fault message and a custom error code
> (the latter of which by the way never seemed to get sent, it is always
> zero
> on arrival) and then "manually" pre-check for a fault struct myself and
> throw an XmlRpcException accordingly on the client-side.
> How is a handler supposed to _properly_ signal the faulty password or
> username in such a case?
> Are fault responses not meant to be used by the "user"?
> Do I have an old version (or am I doing something else wrong) that
> received
> fault responses aren't signaled by automatically throwing an
> XmlRpcException
> on the client-side?
> Thanks for any help!
> Sincerely,
> Chris Kay

View raw message