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

[Justin Johnson]

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.

-Justin


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
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
>