Disagree. I do this kind of code all the time:

   try:
      something()
   except:
      log_tons_of_debug_info()
      raise

and I am very glad that I get my debug info works even if I press Ctrl-C or someone calls sys.exit().

Just noting it here: your code is incorrect. In case of a KeyboardInterrupt error and another error raised by `log_tons_of_debug_info()` (there's no error free code, right?), KeyboardInterrupt would end up being masked (it would go into the __context__ attribute of another error). The program won't abort its execution. And it's just one example out of many where it's critical to not mask error types.

Correct code would be:

   try:
      something()
   except BaseException as ex:
      try:
          log_tons_of_debug_info()
      finally:
          raise ex

But really, you don't want to mess with BaseExceptions at all, so just do `except Exception` instead of a bare `except:`.

Why wouldn't I want to mess with BaseExceptions? They are not magic, and add only 3 classes to the list:

SystemExit - You _definitely_ want to catch this one for logging. If a library (not top-level app) calls `sys.exit` you at least want to know what's happening, if anything so you can talk to author and get them to use proper exception types.

KeyboardInterrupt - I normally want to catch this one as well. If the program was taking too long and I hit Ctrl-C to stop it, I _do_ want to see all the debug output. And if I don't, for some reason, there is always Ctrl-\ which kills python immediately and unconditionally.

GeneratorExit - this one is tricky and I agree that in a lot of cases, you don't want to print logs on it. But it also very rare - it only appears in async functions (emitted by yield), and never propagated to caller. So as long as you are not doing async, you can simply ignore it, which covers majority of the the code I write.

Because accidentally masking some BaseExceptions like `asyncio.CancelledError` can lead to things like memory/resource leaks and potentially your production app going down in pretty hard to debug ways.

well, yeah, you don't want to mask any of those. Thats why all my examples talk about logging + re-raising.

> Just noting it here: your code is incorrect. In case of a KeyboardInterrupt error and another error raised by `log_tons_of_debug_info()` (there's no error free code, right?), KeyboardInterrupt would end up being masked (it would go into the __context__ attribute of another error).

Your snippet has the opposite problem: if ex is a regular Exception, but then KeyboardInterrupt is raised by `log_tons_of_debug_info()`, then your snippet would mask that by re-raising ex in its place. I think the original snippet is probably better on balance, even ignoring difference in code complexity.

I dunno, this just usually means I’m going to hold control and mash C, hopefully I can get my interrupt to occur inside your except

Signals are non-reentrant.

You know about Ctrl-\, right? Kills python right away, no exceptions or anything.

(there is also coredump but most distros disable or hide them, so it's not a problem in practice)

Anyone reading your code is going to assume this is a bug. The PEP is right that explicit is better than implicit. You should write `except BaseException` (whether or not this PEP is approved).

"except:" is explicit enough and "except BaseException" is redundant.

Moreover I think there is a real risk people are going to write "except Exception:" instead, which breaks in the fringe case an exception that derives from BaseException (enforced by interpreter) but not from Exception is thrown.

Even if catch Exception is what users usually mean, changing code from "catch (BaseException):" to "catch Exception:" may break some code if improperly reviewed.

It's also not worth breaking production code over this.

> "except:" is explicit enough and "except BaseException" is redundant.

Take that up with the consensus view of the python community, as reflected by python linters in their default configuration, almost all of which warn on bare except.

The debate in the PEP is whether this should be a syntax error. The debate about whether it is good style is over though.

> It's also not worth breaking production code over this.

Agreed.

> Take that up with the consensus view of the python community, as reflected by python linters in their default configuration, almost all of which warn on bare except.

I don't fully agree on it being a purely a style issue (though the warnings from linters are wholly justified). From what I understand, "except:" is a code smell because you don't actually want to catch BaseException instead of just Exception.

Linters wouldn't have warned about it if it meant "except Exception:". The real issue, IMO, is the fact non-exceptions (Ctrl-C, generator exit, program exit code, etc.) have been crammed into the exception system.

>which breaks in the fringe case an exception that derives from BaseException (enforced by interpreter) but not from Exception is thrown.

For many users, in many cases, this would be fixing the code rather than breaking it.

Forcing people to write either `except BaseException:` or `except Exception:` means forcing them to think about which one they actually mean. This is a good thing, just like the enforcement of proper separation between bytes and text is a good thing.

Only if they don't understand what 'raise' means. It's obvious this construct is just injecting some additional information in a passing exception, there's no issue if it catches everything.

> It's obvious this construct is just injecting some additional information in a passing exception

There is a good chance it will fail to do that. See elsewhere in this thread.

It will change exception class if logging function will fail... I wouldn't call this "good chance", those kinds of things are pretty unlikely in my experience.

Bare except + reraise is a very common Python pattern, so no, it won't be assumed to be a bug. This was actually one of the major points in the discussion of the PEP that led to its rejection.

Java solved the problem by having Throwable as the root of all exceptions and not advertising that fact loudly. The derived Exception class is the root of all safely catchable exceptions. When someone catches a Throwable, something strange is going on.

Python does the same thing. It just calls Throwable something different.

Java Throwable ~= Python BaseException.

Java Exception ~= Python Exception.

The problem here is that a bare except catches something similar to Throwable, not something similar to Exception.

> Bare excepts are syntactic sugar for `except BaseException`.

I'm guessing that a `3to4` script would be provided which replaces bare `except:` with `except BaseException:`. We have the experience of `2to3` to draw on with regards to how that might play out.

EDIT: Haha, I now see that this PEP proposes a change without advancing the major version. That surprises me.

1. Such a script is proposed in the PEP.

2. Python does not use semantic versioning. 3.13 is a different major version to 3.12.

Given what happened with Python 2 => 3, I’m not sure we’ll ever see Python 4.