Returning Fault instances in xmlrpc

[Brian Quinlan]

Magnus Lie Hetland wrote:

> Because of the semantics of xmlrpc. xmlrpc has no notion of
> exceptions, but it does have a notion of Fault objects. 

A rose by any other name :-)

> If the xmlrpc library uses exceptions in lieu of Fault objects, but 
> *also* uses fault objects, and these two behave differently, then it 
> is moving away from xmlrpc, and in a way the same operation (in the 
> eyes of xmlrpc) may have two different results. I find that a 
> pretty serious flaw -- if it is indeed the case.

It a Fault object is returned by an XML-RPC function, it is marshaled
just like any other instance. It has no special meaning to
SimpleXMLRPCServer/xmlrpclib in this context. Instances are marshaled by
packaging them as structs. 

> I'm using SimpleXMLRPCServer.

Good choice :-)
 
> Yes, I've noticed that -- and it seems reasonable. I was just confused
> that returning Fault objects was legal, but they were turned into
> mappings. But I guess SimpleXMLRPCServer may allow non-xmlrpc return
> values in general, perhaps.

See above.

> > The xmlrpclib client code raises xmlrpclib.Fault objects in response
to
> > XML-RPC faults.
> 
> Yes, but not if you return them from a SimpleXMLRPCServer, because
> then they are transformed into something else... I guess that's what I
> find odd. But if this is just the standard behaviour for returning
> instances, I guess it's not that illogical.

It is completely rational :-)

Cheers,
Brian