<div class="gmail_quote">On Thu, Aug 13, 2009 at 10:32 AM, Matt Bennett <span dir="ltr"><<a href="mailto:matt@bennett.name">matt@bennett.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My exceptions subclass pb.Error, which means tracebacks are suppressed<br>
on the server and errbacks triggered on the client, exactly as I'd<br>
hoped. What I'm confused about though, is why the<br>
serialization/deserialization process reduces my nice structured<br>
exception into a mere string. Isn't PB's raison d'être to allow you to<br>
send fully formed Python classes over the wire?<br></blockquote></div><br>It's been a while since I worked with this, but I believe the rationale goes something like this:<br><br>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.<br>
<br>If exceptions contained structured data, there's a risk that that data will <i>also</i> 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.<br>
<br>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).<br>
<br>(I could be wrong, but I believe that is the intent.)<br>