Hacker News Reader

Comment by williamsmj | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com