On Thu, Aug 13, 2009 at 10:32 AM, Matt Bennett <[email protected]> wrote:
> My exceptions subclass pb.Error, which means tracebacks are suppressed > on the server and errbacks triggered on the client, exactly as I'd > hoped. What I'm confused about though, is why the > serialization/deserialization process reduces my nice structured > exception into a mere string. Isn't PB's raison d'être to allow you to > send fully formed Python classes over the wire? > It's been a while since I worked with this, but I believe the rationale goes something like this: the most common type of error in PB is a serialization or deserialization error. You sent too much, you didn't send enough, your jellier doesn't quite match your unjellier, there's a version skew problem. If exceptions contained structured data, there's a risk that that data will *also* have a serialization error; or, worse yet, attempt to include the problematic data which caused the error in the first place. So it's generally not a good idea to work around this, because you can easily cause a mutually recursive loop where reporting the error causes another error that needs to be reported. That said, based on memory and a brief read-through of the code, PB does support returning structured exceptions; you can't just return a normal Exception subclass, you need to register it as serializable the same way you would any other object, and it needs to subclass Jellyable (for example by subclassing Copyable). (I could be wrong, but I believe that is the intent.)
_______________________________________________ Twisted-Python mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
