On Fri, Jan 3, 2014 at 4:16 PM, Rustom Mody <rustompm...@gmail.com> wrote: > Something like this is what I had in mind > http://help.openerp.com/question/9704/how-to-read-and-understand-errors-from-tracebacks/ >
Hrm, site's having trouble. First time I tried it, it came back with a gateway timeout. Seemed to work second time, though, so now I have the content up. That sort of thing is fine when you're working with a very specific framework. (Look at point 6, for instance. Knowing the boundary between "code we trust because it's really thoroughly tested" and "code that might be the cause of the bug" means knowing what the framework is, usually.) If you understand the code enough to pinpoint the problem, you probably know enough to fix the problem, and if you don't, you can save yourself a lot of analysis by just posting the whole traceback for someone else to read. So while that advice may be helpful on that site's forum, for the general field of python-list it's probably more useful to just tell people to quote the whole traceback, and then we can figure things out. That's the "advice for python-list" part, though. What about the opposite side of that - helping people to understand their own code? Well, it's what I said in the parens about knowing the boundary. This is completely language-independent now; I had the same thing come up in REXX, the same thing will happen if you're debugging something in gdb, and it happens to me all the time in Pike. In all four languages it's common for the actual exception (or signal, in the case of gdb) to emanate from somewhere below user code. So there are two options: Either get so familiar with the library code that you recognize where to stop reading, or get so familiar with the code you're debugging that you recognize where to start reading. The first one is great for users-helping-users forums, the second is superb for your own code :) And if you can't do either of those, a crystal ball helps alot; chances are an expert can go to the right area even without knowing the code, just by what "looks right" and what "looks wrong". A handy fallback. ChrisA PS. I left a typo in there because I'd love to see a drawing of a crystal ball helping Alot. http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at-everything.html -- https://mail.python.org/mailman/listinfo/python-list
