[reportlab-users] Tracing and Debugging support in Platypus

Andy Robinson reportlab-users@reportlab.com
Sun, 9 Nov 2003 00:52:38 -0000


I've been working on debug support for RML2PDF and, as a
consequence, for Platypus.  I have a checkin ready but would
love some second opinions on this...

The problems:  
(1) An error occurs during doc.build (the platypus main loop).  
But your story was built dynamically out of objects from
other places. You want a reasonable way to put in trace info, so 
you can find out how far the story got and which object is causing 
trouble.  (e.g. an impossible layout constraint or some null
data in a table cell, but you don't know which of a zillion
tables...)

(2) Your story was assembled from lots of code in lots of
modules (in our case, often preprocessors assembling chunks
of XML from different "source files").  You have the option
to add info on where things came from when coding. You'd like to 
track runtime errors back to the original source files and line
numbers, or database records, or whatever.  


Outline solution:
1. Define a little 'TraceInfo' object which can hold extra
info about original source files and line numbers; and could
bbe subclassed to hold anything you want (like, maybe a 
record ID from a database).  Every flowable has an attribute 
_traceInfo which is None by default.

2. the Platypus main loop gets a try/except handler.
If an error occurs handling a flowable, AND it has
a _traceInfo object, it intercepts the error; grabs
the message; and lets the traceInfo object append a second line 
to the traceback message with the extra info; then re-raises the 
error.

In our own RML product I can now run in a debug mode and
get tracebacks telling me the line and character number of the 
tag which caused the error.

However, all this solution does is trap errors.  I wonder if
it would be even better to allow some kind of logger, and
give flowables a chance to write to it?  So, you could
run in a debug mode and create a file showing where your
code got to before it died.  We could perhaps even save
a text version of the story in a log file in a standard
way on the way through.

Ideas/requests most welcome.

- Andy