try:
# Sth which might throw whatever,
# but we could still proceed afterwards with reasonable
# fallback logic, or just skip this.
...
except Exception:
print("Warning: XY failed...")
# print stack trace, but then proceed
sys.excepthook(*sys.exc_info())
For try excerpt scenario yoi described the Logging.exception method is my favorite way to print the traces: https://docs.python.org/3/library/logging.html#logging.Logge.... Using that you don’t have to catch any particular exception and the trace will be output everywhere you have a logging handler configured.
> I wonder, when you already run this within PyCharm, why not just set breakpoints and use the PyCharm debugger?
It's not just PyCharm. A debugger can be set up in many other development environments, but it seems some people refuse to use a debugger. I've seen this more in the PHP community, where people swear that they'll never use a debugger and say there's no need to learn because putting `var_dump` everywhere is better.
For sure, packages like these have their places, but if you're using it for debugging, you're doing software development wrong.
I can sympathize, though, with situations like trying to use a remote debugger when there's a distributed backend of php services. In that case, your var_dump gets distributed everywhere too, so you don't need to chase where the request went to.
Helps so much when trying to track down random unhandled promise rejection / async errors that don't always execute linearly with the rest of the program flow.
In my company this was done rather less hacky-ly in PHP: the logger accepted an exception and printed its backtrace. Stray exceptions are captured at the top. ‘Idea’ IDEs already recognize paths like ‘/dev/printstack/examples/example.py:3’ and link them straight to the line. In the web logger interface, that was linked to the web git interface (in theory could be linked to a custom desktop protocol though). In the terminal, e.g. iTerm can process various formats on hover and link to apps or custom protocols.
Custom protocols are generally an okayish glue between the browser and other apps, e.g. you can add notes to Org-mode or call other Emacs functions. And the protocols also work from other apps, of course—like Alfred.
I wrote a log function for debugging which does something similar for my own projects, but this is even easier to implement, and provides superior output.
For unhandled exceptions, I have also my own little package: https://github.com/albertz/py_better_exchook
I sometimes also wrap this like: