Jeff Watkins wrote:
Actually, I found the problem and it WAS in my code, only Kid made it
200 times more difficult to track down the problem. See my most recent
message in the "*SQLObject transaction problems" thread.*
*I agree that debugging TurboGears applications is nightmarish at the
moment. I can only hope that's going to improve. At least when I was
doing JSPs, I had some prayer of knowing what line the error appeared on.*
*
*
Well, I still think that if cleanup is going to be done from with an
except block that the original traceback needs to be printed/logged
*prior* to anything else happening, i.e. as close to the point of
failure as possible. Consider:
>>> try:
... print x
... except:
... print y
... raise
...
Traceback (most recent call last):
File "<stdin>", line 4, in ?
NameError: name 'y' is not defined
>>>
The cause of the original error is lost. Put that a few layers of
abstraction down and you've got fun. Better to do this:
>>> import sys, traceback
>>> try:
... print x
... except:
... traceback.print_exc(file = sys.stdout)
... print y
... raise
...
Traceback (most recent call last):
File "<stdin>", line 2, in ?
NameError: name 'x' is not defined
Traceback (most recent call last):
File "<stdin>", line 5, in ?
NameError: name 'y' is not defined
>>>
*Much* easier to track down. I think a couple hours with grep
searching for exception blocks and adding some code to print/log/save
the traceback would go a long way to making debugging apps easier. Of
course, if you do much more than printing the exception, great care must
be taken that *that* code doesn't raise an exception itself ;-)
Regards,
Cliff
