3 ms·
I once wrote something similar: https://github.com/albertz/py_better_exchook https://github.com/albertz/py_better_exchook Example: https://gist.github.com/albe
by albertzeyer 12y ago
I once wrote something similar: https://github.com/albertz/py_better_exchook https://github.com/albertz/py_better_exchook
Example: https://gist.github.com/albertz/922622 https://gist.github.com/albertz/922622
It does not dump all local vars though, only those which appear in the line where the exception happened. And not only local but also global. But also including subfields, like `obj.field`. And it does that in a kind of hacky way, via some embedded simple Python parsing, but it works most of the way just fine.
- brianr 12y agoVery nice. Did you find globals to be useful often? We excluded those here because there can be a lot of them (i.e. imported modules), but could be a good addition. `obj.field` is a nice touch too (our current approach will work if repr() shows the field, but that requires some code ahead of time).
- albertzeyer 12y agoThat's why I only include those globals which are referred to in the line of the exception. And when they were referred in the line, they often were also useful. Otherwise, you are right, way too many to show all. I even found all the locals to be too many in many cases, that's why I did that simple heuristics. Also, I just made this to be a `sys.excepthook` replacement, so it's just text and you cannot simply hide the locals away and a simple traceback would just look too long/complicated.