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 ``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 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 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 Changes to the language are required in order to extend support for
exception groups in the style of existing exception handling mechanisms. At 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. for this purpose, in a backwards-compatible manner, and found that it is not.
See the `Rejected Ideas`_ section for more on this. See the `Rejected Ideas`_ section for more on this.
The purpose of this PEP, then, is to add the ``except*`` syntax for handling The purpose of this PEP, then, is to add the ``ExceptionGroup`` builtin type
exception groups in the interpreter, which in turn requires that and the ``except*`` syntax for handling exception groups in the interpreter.
``ExceptionGroup`` is added as a builtin type. The desired semantics of The desired semantics of ``except*`` are sufficiently different from the
``except*`` are sufficiently different from the current exception current exception handling semantics that we are not proposing to modify the
handling semantics that we are not proposing to modify the behavior of the behavior of the ``except`` keyword but rather to add the new ``except*``
``except`` keyword but rather to add the new ``except*`` syntax. syntax.
Our premise is that exception groups and ``except*`` will be used Our premise is that exception groups and ``except*`` will be used
selectively, only when they are needed. We do not expect them to become selectively, only when they are needed. We do not expect them to become