[Twisted-Python] Re: Trouble with pb.CopyableFailure

[David Bolen]

Justin Johnson <justinjohnson at gmail.com> writes:

> Does anyone know what I'm doing wrong here?  I've searched through the
> docs but don't see specific examples of how to use CopyableFailure, so
> I made the assumption that I could raise a CopyableFailure instead of
> specifically writing code to send the failure back to the client.  Any
> help is appreciated.

I don't think CopyableFailure is supported in that manner.  The
support for returning information on remote exceptions is in pb.py in
the _recvMessage function of the Broker class.  In general:

* If the exception is a subclass of pb.Error then it is wrapped in a
  CopyableFailure (using the exception information) and without any
  local logging of the exception.
* For any other exception a CopyableFailure is created using the current
  exception information (sys.exc_info()) and that is sent back along
  with local logging of the exception.

The use of CopyableFailure is pretty much an internal implementation detail
in order to get the Failure instance across to the remote client, and
doesn't appear to be designed to be subclassed.

So it depends on what you're trying to do.  If you just want to get
the failure indication back to your client, you should just be able to
raise any old exception (subclass pb.Error if you don't want a local
log about the exception), and it will get passed over automatically,
and show up as a Failure object suitable for use with errbacks,
failure.trap() and so on.

If however you specifically want to get across your custom exception
with additional information, you'll have some issues with or without
CopyableFailure, since the eventual CopyableFailure that such remote
transmissions get wrapped in transmits the actual exception instance
turned into a string name and without any local exception instance
data.  It still works fine with twisted code for errbacks and
failure.trap() since that code knows how to match up a failure by
class name, but it bit us when we specifically wanted the remote side
to have access to a functioning custom exception object with
additional attributes.  While we haven't done it yet, the only way we
anticipate to handle this is with some local modifications to how the
exceptions are transmitted through the CopyableFailure process (either
simply pickling the exception in our case since we understand our
security environment, or reusing existing jelly registration for the
underlying exception class).

-- David