[Twisted-Python] Re: Trouble with pb.CopyableFailure
justinjohnson at gmail.com
Thu Nov 11 16:30:08 EST 2004
Thanks for the reply. Yes, I am trying to pass back my custom failure
with its attributes. I had a feeling this might be the case, so for
now I did pattern matching on the string representation of the failure
once passed back and extracted the attributes that way, since the
attributes I need are just strings anyway. Pretty hacky, but it'll
have to do for now.
On 11 Nov 2004 14:38:30 -0500, David Bolen <db3l at fitlinxx.com> wrote:
> 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
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
More information about the Twisted-Python