[Twisted-Python] jelly tracebacks

[Brian Warner]

> I just had a grueling experience debugging some
> unjellying problem. I wonder, why not make jelly
> tracebacks more useful by adding the details of the PB
> message that gave rise to them (i.e. which method of
> which object was called with which arguments). Any
> thoughts?

Good idea. I've incorporated this into newpb, where any problem during
serialization or unserialization is reported via an exception that has a
.where attribute. This .where string reports the location in the object graph
that had the problem. In the case of serialization errors during an argument
of a method call, you'd get a string with something like:

 <call-(reqID)-(objID)-(methodname)>.foo

If you were to have something unserializable inside a container, the .where
string would include the relevant index values:

 d = {'foo': 12, 'bar': Ephemeral()}
 l = [1, 2, d]
 rr.callRemote("doStuff", arg1=5, arg2=l)
   -> BananaError(where=<call-0-4-doStuff>.arg2[2]['bar'])

Likewise, if one of the arguments violates a Schema constraint, the exception
should give you enough information to figure out what exactly caused the
problem. This occurs on both ends of the wire, so exceptions that occur when
serializing the return value can be located too.

The same .where technique is used during unserialization, so if someone sends
you a serialized instance of a class that you are unaware of (or unwilling to
deserialize), or if their value violates your inbound schema, you'll get an
exception that has enough detail to help you figure out where exactly the
problem was.

cheers,
 -Brian