[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