Chris, 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. Mike > ---------- > From: Chris Kay > Reply To: [EMAIL PROTECTED] > Sent: Tuesday, July 9, 2002 12:08 AM > To: [EMAIL PROTECTED] > 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 > >
