[Twisted-Python] Re: More on PB Copyable Errors

David Bolen db3l at fitlinxx.com
Wed Dec 29 18:38:05 MST 2004


Christopher Armstrong <radeex at gmail.com> writes:

(...)
> Why's that actually a risk? In any case where a PB app uses Copyable
> and suchlike, that assumption is made. If someone is marking an
> exception as jellyable, then they know that their clients should also
> be able to unjelly that exception, and it will be a part of the
> protocol.

Yeah, that's reasonable.  It doesn't cover a desire to transmit system
exceptions (e.g., we sometimes reuse ValueError rather than redefining our
own version of it), but at worst you'd just need to build a mirror
hierarchy for those system exceptions you might reuse.

(...)
> That's exactly what the patch would do, AIUI. On the server side, you
> can set unsafeTracebacks if you want tracebacks to be sent to the
> client. The server side can also set an exception class as jellyable
> if you want to send exception instances to the client.

Well, the patch is checking the unjelly registry to make the encoding
decision on the server side, which I don't think is the same thing as
what you're saying.  To check for whether the exception was marked as
jellyable, it should be checking for a subclass of Jellyable and not
looking in the unjelly registry (I think).

But yeah, if the patch looked for a Jellyable subclass (which is the
same thing the normal _Jellier class does when jellying anything
else), I think that would be a reasonable approach.

-- David






More information about the Twisted-Python mailing list