From cf87703454f15923aa316486c9ccc31bfac72a49 Mon Sep 17 00:00:00 2001 From: Irit Katriel Date: Mon, 8 Mar 2021 17:23:30 +0000 Subject: [PATCH] PEP 654: add to the rejected ideas section, following public discussion (#1863) --- pep-0654.rst | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) diff --git a/pep-0654.rst b/pep-0654.rst index 667a5262c05..d05f1fcdf5f 100644 --- a/pep-0654.rst +++ b/pep-0654.rst @@ -1110,6 +1110,39 @@ We did, however, provide there the code for a traversal algorithm that correctly constructs each leaf exceptions' metadata. If it does turn out to be useful in practice, we can add that utility to the standard library. +Make ``ExceptionGroup`` Extend ``BaseException`` +------------------------------------------------ + +We considered making ``ExceptionGroup`` subclass only ``BaseException``, +and not ``Exception``. The rationale of this was that we expect exception +groups to be used in a deliberate manner where they are needed, and raised +only by APIs that are specifically designed and documented to do so. In +this context, an ``ExceptionGroup`` escaping from an API that is not +intended to raise one is a bug, and we wanted to give it "fatal error" +status so that ``except Exception`` will not inadvertently swallow it. +This would have been consistent with the way ``except T:`` does not catch +exception groups that contain ``T`` for all other types, and would help +contain ``ExceptionGroups`` to the parts of the program in which they are +supposed to appear. However, it was clear from the public discussion that +``T=Exception`` is a special case, and there are developers who feel strongly +that ``except Exception:`` should catch "almost everything", including +exception groups. This is why we decided to make ``ExceptionGroup`` a +subclass of ``Exception``. + +Make it Impossible to Wrap ``BaseExceptions`` in an Exception Group +------------------------------------------------------------------- + +A consequence of the decision to make ``ExceptionGroup`` extend +``Exception`` is that ``ExceptionGroup`` should not wrap ``BaseExceptions`` +like ``KeyboardInterrupt``, as they are not currently caught by +``except Exception:``. We considered the option of simply making it +impossible to wrap ``BaseExceptions``, but eventually decided to make +it possible through the ``BaseExceptionGroup`` type, which extends +``BaseException`` rather than ``Exception``. Making this possible +adds flexibility to the language and leaves it for the programmer to +weigh the benefit of wrapping ``BaseExceptions`` rather than propagating +them in their naked form while discarding any other exceptions. + Traceback Representation ------------------------ @@ -1147,6 +1180,18 @@ clauses with the knowledge that they are only executed once. If there is a non-idempotent operation there, such as releasing a resource, the repetition could be harmful. +Another option that came up in the public discussion was to add ``except*``, +but also make ``except`` treat ``ExceptionGroups`` as a special case. +``except`` would then do something along the lines of extracting one exception +of matching type from the group in order to handle it. The motivation behind +these suggestions was to make the adoption of exception groups safer, in that +``except T`` catches ``Ts`` that are wrapped in exception groups. We decided +that such an approach adds considerable complexity to the semantics of the +language without making it more powerful. Even if it would make the adoption +of exception groups slightly easier (which is not at all obvious), these are +not the semantics we would like to have in the long term. + + A New ``except`` Alternative ----------------------------