<div class="gmail_quote">On Thu, Aug 13, 2009 at 10:32 AM, Matt Bennett <span dir="ltr">&lt;<a href="mailto:matt@bennett.name">matt@bennett.name</a>&gt;</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&#39;d<br>
hoped. What I&#39;m confused about though, is why the<br>
serialization/deserialization process reduces my nice structured<br>
exception into a mere string. Isn&#39;t PB&#39;s raison d&#39;être to allow you to<br>
send fully formed Python classes over the wire?<br></blockquote></div><br>It&#39;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&#39;t send enough, your jellier doesn&#39;t quite match your unjellier, there&#39;s a version skew problem.<br>
<br>If exceptions contained structured data, there&#39;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&#39;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&#39;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>