Hacker News Reader

Comment by albertzeyer | Hacker News Reader

I wonder, when you already run this within PyCharm, why not just set breakpoints and use the PyCharm debugger?

For unhandled exceptions, I have also my own little package: https://github.com/albertz/py_better_exchook

I sometimes also wrap this like:

    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())

View on HN

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.

For me, unit tests is what's replaced the debugger.

I still try to fire up the PyCharm debugger sometimes, but setting up the environment usually proves too hard.

Reply on news.ycombinator.com