Dan Eloff wrote .. > I grew tired of scrolling down through the very long tracbacks to get > to the actual error, so I wrote a function that lets me skip > everything up to my handler function. While I was at it I figured I > may as well highlight the things I want to see to make the tracebacks > easier to read. When I was finished I liked it so much I had to share, > it would be nice if this found it's way into mod_python. To adapt it > for your purposes, change the condition func == 'handler' to something > else (you probably don't want to cut out the call to handler like me.) > Please excuse my lousy html, I wrote it to be small so it didn't > clutter up my source, I hate html in my python code. Feel free to > change whatever you like.
I'll agree that mod_python 3.3 tracebacks are perhaps longer than they need to be given that I factored out various stuff into some functions so as to be able to reuse it across connection, handler and filter dispatch. I also like the idea of using colour to highlight important stuff. Thus, probably a good time to upgrade the standard traceback page that mod_python generates when there is an error. In others words, incorporate your ideas into the CallBack.ReportError function in the mod_python.apache module. When integrated, will have to be a bit more tricky to deal with fact that could be any phase and handler name for phase can be overridden. The information to do all that should be available though. Anyone else got any other ideas of what to put in the page? For example, perhaps stuff like what req.filename, req.path_info, req.uri etc are set to. Once we get a feel what would be good to see, I'll create a JIRA issue for it and reference the discussion in the mailing list archive. With all my talk of dependency graphs, am thinking I could also put that code in mod_python.testhandler module so as to be optionally used by people as an aid for debugging applications as well. Graham
