iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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

This commit is contained in:
Irit Katriel 2021-03-27 22:16:43 +00:00 committed by GitHub
parent 59b39a6dd0
commit 31e30aebe1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
pep-0654.rst
View File

@ -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
@ -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