[Twisted-Python] Pass error (exception) message to XMLRPC client

[Jp Calderone]

On Thu, 28 Apr 2005 10:59:57 +0200, Remy Cool <mailinglists at smartology.nl> wrote:
>Brett Viren wrote:
>>Remy C Cool <remy.cool at smartology.nl> writes:
>>>Hello,
>>>
>>>I've searched on the (Twisted) website and mailinglists, but failed to
>>>find the answer to my question.
>>>
>>>Is is possible to pass the original exception code/message to the
>>>XMLRPC client? When an exception occurs, the client get's a general
>>>'error occured' message and I would like to be able to let the client
>>>know what went wrong. How can I accomplish this with Twisted?
>>
>>
>>It isn't really an exception but I use the idiom of returning an
>>(int,string) tuple:
>>
>>   (err,error_message)
>>
>>If err != 0, it's interpreted as an error code.  A successful return
>>is (0,"").
>>
>>I don't happen to do it, but I suppose you could then raise an
>>exception on the client size by hand when non-zero is returned.
>
>That's one way to process exceptions, but that's not what I want. You
>will need to catch all exceptions yourself and send back a tupple as you
>described above. XMLRPC support exception handling, and I would like to
>  use that mechanism rather then coding my own solution.
>
>If an exception occurs in the backend (XMLRPC server) the client
>receives an XMLRPC error (created by Twisted?). My question was and is,
>if it is possible to send the 'real' exception message to the client in
>place of the general message it now receives.
>

  The behavior of that Fault is defined the _ebRender method of  twisted.web.client.xmlrpc.XMLRPC.  Presently it is defined as:

    def _ebRender(self, failure):
        if isinstance(failure.value, Fault):
            return failure.value
        log.err(failure)
        return Fault(self.FAILURE, "error")

  Which logs complete error information on the server and sends minimal information to the client.  If you override this method, you can cause more information to be sent to the client.  It probably avoids doing this currently in case the string version of the failure contains sensitive information.

  Note that _ebRender is private and so may change at any time.  You should be prepared to deal with this, or override the render() method itself and set up your own errback, or contribute a patch that adds a public API for handling all unexpected errors in code invoked from an XMLRPC resource.

  Jp