5 ms·
If you like this, you might also like my small debugging utility, a better_exchook replacement: https://github.com/albertz/py_better_exchook https://github.com/
by albertzeyer 6y ago
If you like this, you might also like my small debugging utility, a better_exchook replacement: https://github.com/albertz/py_better_exchook https://github.com/albertz/py_better_exchook
Simple example:
assert x == 4
When this fails, it will print the value of `x`.
- zomglings 6y agoJust a point of curiosity about reassigning `sys.excepthook`. Is there a reason you simply reassign it and lose information about the old excepthook: sys.excepthook = better_exchook instead of something like: def generate_better_exchook(..., current_excepthook=None): previous_excepthook = current_excepthook def better_exchook(exception_type, exception_instance, exception_traceback): ... if previous_excepthook is not None: previous_excepthook(exception_type, exception_instance, exception_traceback) return better_exchook and then sys.excepthook = generate_better_excepthook(..., sys.excepthook) Do you prefer not to do this because it would keep this closure around in memory until the Python process exits?
- albertzeyer 6y agoHey, sorry, just saw this question right now. Actually, I don't know. I assume this is not standard, because many excepthook handlers would probably print some variant of the stack trace on stdout or stderr, and then you would end up having printed the stack trace multiple times. Or maybe it depends. If your excepthook instead prints it somewhere else (e.g. some log file), it makes sense to also call the default handler afterwards. But no, this is not about the closure.