Skip to content

PEP-654: clarify that ExceptionGroup is not trivial to implement correctly #1894

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
gvanrossum merged 1 commit into from
Mar 27, 2021
Merged

PEP-654: clarify that ExceptionGroup is not trivial to implement correctly #1894

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 10 additions & 7 deletions pep-0654.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -98,7 +98,10 @@ Trio [2]_ is an example of a library that has made use of this technique in its
``MultiError`` [9]_ type. However, such an approach requires calling code to catch
the container exception type, and then to inspect it to determine the types of
errors that had occurred, extract the ones it wants to handle, and reraise the
rest.
rest. Furthermore, exceptions in Python have important information attached to
their ``__traceback__``, ``__cause__`` and ``__context__`` fields, and
designing a container type that preserves the integrity of this information
requires care; it is not as simple as collecting exceptions into a set.

Changes to the language are required in order to extend support for
exception groups in the style of existing exception handling mechanisms. At
Expand All @@ -112,12 +115,12 @@ We considered whether it is possible to modify the semantics of ``except``
for this purpose, in a backwards-compatible manner, and found that it is not.
See the `Rejected Ideas`_ section for more on this.

The purpose of this PEP, then, is to add the ``except*`` syntax for handling
exception groups in the interpreter, which in turn requires that
``ExceptionGroup`` is added as a builtin type. The desired semantics of
``except*`` are sufficiently different from the current exception
handling semantics that we are not proposing to modify the behavior of the
``except`` keyword but rather to add the new ``except*`` syntax.
The purpose of this PEP, then, is to add the ``ExceptionGroup`` builtin type
and the ``except*`` syntax for handling exception groups in the interpreter.
The desired semantics of ``except*`` are sufficiently different from the
current exception handling semantics that we are not proposing to modify the
behavior of the ``except`` keyword but rather to add the new ``except*``
syntax.

Our premise is that exception groups and ``except*`` will be used
selectively, only when they are needed. We do not expect them to become
Expand Down