Hacker News Reader

Comment by OscarCunningham | Hacker News Reader

One example of a time I used a bare except was when I wanted a program to retry three times if it failed for any reason. I just wrapped everything in a for loop with a catchall except.

The problem occurred when our scheduling program (Airflow) noticed the program was taking too long to run and decided to kill it. It sent a kill signal to Python, which dutifully caught the exception, retried and continued to run. I had to add a special case to allow Airflow to kill the program.

This PEP just forced me to look up the difference between the classes Exception and BaseException. It turns out that BaseException includes every exception, whereas Exception excludes those that are trying to exit the program (like SystemExit and KeyboardInterrupt).

View on HN

With a bare except, your code will continue to retry even if SystemExit or KeyboardInterrupt is raised. This is almost always a bug.

In other words, your comment is an argument for the proposal!

I don't think it's a good enough argument to make a backwards incompatible change. This is a wart Python has to live with now. But I do think it's a shame that bare excepts behave in a way that is almost always a bug.

Maybe bare excepts could be modified to just catch Exceptions. It seems like a reasonable expression of the idea: everything that could go with my program but not with the OS.

Personally I think that would have been a better choice in Python's original design, but to change it now would be a backwards-incompatible change, i.e. it suffers from the same big problem everyone is highlighting in the PEP.

That seems less bad in the sense it would affect fewer people, but the ones it did affect would likely be much more strongly affected. For instance, I could imagine someone with an old daemon that had a too-level loop like:

  while True:
      try:
          serve()
      except:
          log(‘oops’)

so that it was more or less bulletproof. This might be a highly unpleasant change for those people who counted on it running 24/7 and never dying.

In other words, the current behavior is a minor hassle for many people. That change would be a major hassle for a few.

I’d be all for a deprecation warning on bare excepts. That might nudge a lot of people to fix their code without actively breaking anything.

> I’d be all for a deprecation warning on bare excepts. That might nudge a lot of people to fix their code without actively breaking anything.

The PEP proposes a deprecation timeline for exactly this.

Thank you for being honest about making the exact mistake they are trying to help out with this.

I’ll restate what I posted elsewhere, I have never come across anyone who actually wanted to write a bare except, only people who thought naively that it worked like “except Exception” actually does.

I understand people are grabbing pitchforks because everyone has at o e time or another written code using a bare except and they are thinking that this will break it, but they 100% intended that to work like “except exception” python could just make that the default for the bare exemption and keep the syntax.

Depreciating the behavior is a good choice, and anyone who actually wants to capture exit events or keyboard interrupt can explicitly capture those. If code breaks with this depreciation it’s because someone is doing something extremely out of the ordinary but isn’t being explicit about it.

Reply on news.ycombinator.com