(original post on dabo-users, moved to dabo-dev) Ed Leafe wrote: > This is one of those cases where the exception handling we built in > works against us. It's needed because it has to rollback any failed > transactions, but it also masks the actual location of the code that > is causing the problem.
This is such a royal PITA, and I know I've spent probably hours of accrued time in commenting out the try blocks to figure out the original exception. I've brainstormed a couple angles to make this easier, but this was only after a couple minutes reflection. I wish I had time to play with it but thought I'd mention it to see it shot down or praised, or even hopefully implemented. :) First thought: Include DEBUG flags in dCursor and dBizobj. When True, don't handle the exceptions and don't re-raise different exceptions. Just let whatever caused the exception (probably coming from the db adapter) to trickle up and print the traceback on stderr like normal. Second thought: Print out the stack trace before re-raising the exception like normal (or save it somewhere to be introspected later). Thoughts on these thoughts? -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
