CINXE.COM

<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta name="color-scheme" content="light dark"> <title>PEP 654 – Exception Groups and except* | peps.python.org</title> <link rel="shortcut icon" href="../_static/py.png"> <link rel="canonical" href="https://peps.python.org/pep-0654/"> <link rel="stylesheet" href="../_static/style.css" type="text/css"> <link rel="stylesheet" href="../_static/mq.css" type="text/css"> <link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light"> <link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark"> <link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss"> <meta property="og:title" content='PEP 654 – Exception Groups and except* | peps.python.org'> <meta property="og:description" content="This document proposes language extensions that allow programs to raise and handle multiple unrelated exceptions simultaneously:"> <meta property="og:type" content="website"> <meta property="og:url" content="https://peps.python.org/pep-0654/"> <meta property="og:site_name" content="Python Enhancement Proposals (PEPs)"> <meta property="og:image" content="https://peps.python.org/_static/og-image.png"> <meta property="og:image:alt" content="Python PEPs"> <meta property="og:image:width" content="200"> <meta property="og:image:height" content="200"> <meta name="description" content="This document proposes language extensions that allow programs to raise and handle multiple unrelated exceptions simultaneously:"> <meta name="theme-color" content="#3776ab"> </head> <body> <svg xmlns="http://www.w3.org/2000/svg" style="display: none;"> <symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all"> <title>Following system colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="9"></circle> <path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path> </svg> </symbol> <symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all"> <title>Selected dark colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <path stroke="none" d="M0 0h24v24H0z" fill="none"></path> <path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path> </svg> </symbol> <symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all"> <title>Selected light colour scheme</title> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"> <circle cx="12" cy="12" r="5"></circle> <line x1="12" y1="1" x2="12" y2="3"></line> <line x1="12" y1="21" x2="12" y2="23"></line> <line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line> <line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line> <line x1="1" y1="12" x2="3" y2="12"></line> <line x1="21" y1="12" x2="23" y2="12"></line> <line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line> <line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line> </svg> </symbol> </svg> <script> document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto" </script> <section id="pep-page-section"> <header> <h1>Python Enhancement Proposals</h1> <ul class="breadcrumbs"> <li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li> <li><a href="../pep-0000/">PEP Index</a> » </li> <li>PEP 654</li> </ul> <button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())"> <svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg> <svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg> Toggle light / dark / auto colour theme </button> </header> <article> <section id="pep-content"> <h1 class="page-title">PEP 654 – Exception Groups and except*</h1> <dl class="rfc2822 field-list simple"> <dt class="field-odd">Author:</dt> <dd class="field-odd">Irit Katriel <irit at python.org>, Yury Selivanov <yury at edgedb.com>, Guido van Rossum <guido at python.org></dd> <dt class="field-even">Discussions-To:</dt> <dd class="field-even"><a class="reference external" href="https://discuss.python.org/t/accepting-pep-654-exception-groups-and-except/10813">Discourse thread</a></dd> <dt class="field-odd">Status:</dt> <dd class="field-odd"><abbr title="Accepted and implementation complete, or no longer active">Final</abbr></dd> <dt class="field-even">Type:</dt> <dd class="field-even"><abbr title="Normative PEP with a new feature for Python, implementation change for CPython or interoperability standard for the ecosystem">Standards Track</abbr></dd> <dt class="field-odd">Created:</dt> <dd class="field-odd">22-Feb-2021</dd> <dt class="field-even">Python-Version:</dt> <dd class="field-even">3.11</dd> <dt class="field-odd">Post-History:</dt> <dd class="field-odd"><a class="reference external" href="https://mail.python.org/archives/list/python-dev@python.org/thread/L5Q27DVKOKZCDNCAWRIQVOZ5DZCZHLRM/" title="Python-Dev thread">22-Feb-2021</a>, <a class="reference external" href="https://mail.python.org/archives/list/python-dev@python.org/thread/MQ2UCSQ2ZC4FIGT7KSVI6BJA4FCXSOCL/" title="Python-Dev thread">20-Mar-2021</a>, <a class="reference external" href="https://mail.python.org/archives/list/python-dev@python.org/thread/4B256YKUPW5P2M44GG5H6FBL3PSV6ODP/" title="Python-Dev thread">03-Oct-2021</a></dd> <dt class="field-even">Resolution:</dt> <dd class="field-even"><a class="reference external" href="https://discuss.python.org/t/accepting-pep-654-exception-groups-and-except/10813/1">Discourse message</a></dd> </dl> <hr class="docutils" /> <section id="contents"> <details><summary>Table of Contents</summary><ul class="simple"> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#motivation">Motivation</a></li> <li><a class="reference internal" href="#rationale">Rationale</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#exceptiongroup-and-baseexceptiongroup">ExceptionGroup and BaseExceptionGroup</a><ul> <li><a class="reference internal" href="#subclassing-exception-groups">Subclassing Exception Groups</a></li> <li><a class="reference internal" href="#the-traceback-of-an-exception-group">The Traceback of an Exception Group</a></li> <li><a class="reference internal" href="#handling-exception-groups">Handling Exception Groups</a></li> </ul> </li> <li><a class="reference internal" href="#except">except*</a><ul> <li><a class="reference internal" href="#recursive-matching">Recursive Matching</a></li> <li><a class="reference internal" href="#unmatched-exceptions">Unmatched Exceptions</a></li> <li><a class="reference internal" href="#naked-exceptions">Naked Exceptions</a></li> <li><a class="reference internal" href="#raising-exceptions-in-an-except-block">Raising exceptions in an <code class="docutils literal notranslate">except*</code> block</a></li> <li><a class="reference internal" href="#chaining">Chaining</a></li> <li><a class="reference internal" href="#raising-new-exceptions">Raising New Exceptions</a></li> <li><a class="reference internal" href="#caught-exception-objects">Caught Exception Objects</a></li> <li><a class="reference internal" href="#forbidden-combinations">Forbidden Combinations</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#backwards-compatibility">Backwards Compatibility</a></li> <li><a class="reference internal" href="#how-to-teach-this">How to Teach This</a></li> <li><a class="reference internal" href="#reference-implementation">Reference Implementation</a></li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#make-exception-groups-iterable">Make Exception Groups Iterable</a></li> <li><a class="reference internal" href="#make-exceptiongroup-extend-baseexception">Make <code class="docutils literal notranslate">ExceptionGroup</code> Extend <code class="docutils literal notranslate">BaseException</code></a></li> <li><a class="reference internal" href="#make-it-impossible-to-wrap-baseexceptions-in-an-exception-group">Make it Impossible to Wrap <code class="docutils literal notranslate">BaseExceptions</code> in an Exception Group</a></li> <li><a class="reference internal" href="#traceback-representation">Traceback Representation</a></li> <li><a class="reference internal" href="#extend-except-to-handle-exception-groups">Extend <code class="docutils literal notranslate">except</code> to Handle Exception Groups</a></li> <li><a class="reference internal" href="#a-new-except-alternative">A New <code class="docutils literal notranslate">except</code> Alternative</a></li> <li><a class="reference internal" href="#applying-an-except-clause-on-one-exception-at-a-time">Applying an <code class="docutils literal notranslate">except*</code> Clause on One Exception at a Time</a></li> <li><a class="reference internal" href="#not-matching-naked-exceptions-in-except">Not Matching Naked Exceptions in <code class="docutils literal notranslate">except*</code></a></li> <li><a class="reference internal" href="#allow-mixing-except-and-except-in-the-same-try">Allow mixing <code class="docutils literal notranslate">except:</code> and <code class="docutils literal notranslate">except*:</code> in the same <code class="docutils literal notranslate">try</code></a></li> <li><a class="reference internal" href="#try-instead-of-except"><code class="docutils literal notranslate">try*</code> instead of <code class="docutils literal notranslate">except*</code></a></li> <li><a class="reference internal" href="#alternative-syntax-options">Alternative syntax options</a></li> </ul> </li> <li><a class="reference internal" href="#programming-without-except">Programming Without ‘except *’</a></li> <li><a class="reference internal" href="#see-also">See Also</a></li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#acceptance">Acceptance</a></li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> </details></section> <div class="pep-banner canonical-doc sticky-banner admonition important"> Important This PEP is a historical document. The up-to-date, canonical documentation can now be found at <a class="reference external" href="https://docs.python.org/3/library/exceptions.html#lib-exception-groups" title="(in Python v3.13)">Exception groups</a> and <a class="reference external" href="https://docs.python.org/3/reference/compound_stmts.html#except-star" title="(in Python v3.13)">except* clause</a>. × See <a class="reference external" href="https://docs.python.org/3/tutorial/errors.html#tut-exception-groups" title="(in Python v3.13)">Raising and Handling Multiple Unrelated Exceptions</a> for a user-focused tutorial. See <a class="pep reference internal" href="../pep-0001/" title="PEP 1 – PEP Purpose and Guidelines">PEP 1</a> for how to propose changes. </div> <section id="abstract"> <h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2> This document proposes language extensions that allow programs to raise and handle multiple unrelated exceptions simultaneously: <ul class="simple"> <li>A new standard exception type, the <code class="docutils literal notranslate">ExceptionGroup</code>, which represents a group of unrelated exceptions being propagated together.</li> <li>A new syntax <code class="docutils literal notranslate">except*</code> for handling <code class="docutils literal notranslate">ExceptionGroups</code>.</li> </ul> </section> <section id="motivation"> <h2><a class="toc-backref" href="#motivation" role="doc-backlink">Motivation</a></h2> The interpreter is currently able to propagate at most one exception at a time. The chaining features introduced in <a class="pep reference internal" href="../pep-3134/" title="PEP 3134 – Exception Chaining and Embedded Tracebacks">PEP 3134</a> link together exceptions that are related to each other as the cause or context, but there are situations where multiple unrelated exceptions need to be propagated together as the stack unwinds. Several real world use cases are listed below. <ul> <li>Concurrent errors. Libraries for async concurrency provide APIs to invoke multiple tasks and return their results in aggregate. There isn’t currently a good way for such libraries to handle situations where multiple tasks raise exceptions. The Python standard library’s <code class="docutils literal notranslate">asyncio.gather()</code> <a class="footnote-reference brackets" href="#id19" id="id1">[1]</a> function provides two options: raise the first exception, or return the exceptions in the results list. The Trio <a class="footnote-reference brackets" href="#id20" id="id2">[2]</a> library has a <code class="docutils literal notranslate">MultiError</code> exception type which it raises to report a collection of errors. Work on this PEP was initially motivated by the difficulties in handling <code class="docutils literal notranslate">MultiErrors</code> <a class="footnote-reference brackets" href="#id27" id="id3">[9]</a>, which are detailed in a design document for an improved version, <code class="docutils literal notranslate">MultiError2</code> <a class="footnote-reference brackets" href="#id21" id="id4">[3]</a>. That document demonstrates how difficult it is to create an effective API for reporting and handling multiple errors without the language changes we are proposing (see also the <a class="reference internal" href="#programming-without-except">Programming Without ‘except *’</a> section.)Implementing a better task spawning API in asyncio, inspired by Trio nurseries <a class="footnote-reference brackets" href="#id31" id="id5">[13]</a>, was the main motivation for this PEP. That work is currently blocked on Python not having native language level support for exception groups. </li> <li>Multiple failures when retrying an operation. The Python standard library’s <code class="docutils literal notranslate">socket.create_connection</code> function may attempt to connect to different addresses, and if all attempts fail it needs to report that to the user. It is an open issue how to aggregate these errors, particularly when they are different (see issue 29980 <a class="footnote-reference brackets" href="#id22" id="id6">[4]</a>.)</li> <li>Multiple user callbacks fail. Python’s <code class="docutils literal notranslate">atexit.register()</code> function allows users to register functions that are called on system exit. If any of them raise exceptions, only the last one is reraised, but it would be better to reraise all of them together (see <code class="docutils literal notranslate">atexit</code> documentation <a class="footnote-reference brackets" href="#id23" id="id7">[5]</a>.) Similarly, the pytest library allows users to register finalizers which are executed at teardown. If more than one of these finalizers raises an exception, only the first is reported to the user. This can be improved with <code class="docutils literal notranslate">ExceptionGroups</code>, as explained in this issue by pytest developer Ran Benita (see pytest issue 8217 <a class="footnote-reference brackets" href="#id24" id="id8">[6]</a>.)</li> <li>Multiple errors in a complex calculation. The Hypothesis library performs automatic bug reduction (simplifying code that demonstrates a bug). In the process it may find variations that generate different errors, and (optionally) reports all of them (see the Hypothesis documentation <a class="footnote-reference brackets" href="#id25" id="id9">[7]</a>.) An <code class="docutils literal notranslate">ExceptionGroup</code> mechanism as we are proposing here can resolve some of the difficulties with debugging that are mentioned in the link above, and which are due to the loss of context/cause information (communicated by Hypothesis Core Developer Zac Hatfield-Dodds).</li> <li>Errors in wrapper code. The Python standard library’s <code class="docutils literal notranslate">tempfile.TemporaryDirectory</code> context manager had an issue where an exception raised during cleanup in <code class="docutils literal notranslate">__exit__</code> effectively masked an exception that the user’s code raised inside the context manager scope. While the user’s exception was chained as the context of the cleanup error, it was not caught by the user’s except clause (see issue 40857 <a class="footnote-reference brackets" href="#id26" id="id10">[8]</a>.)The issue was resolved by making the cleanup code ignore errors, thus sidestepping the multiple exception problem. With the features we propose here, it would be possible for <code class="docutils literal notranslate">__exit__</code> to raise an <code class="docutils literal notranslate">ExceptionGroup</code> containing its own errors along with the user’s errors, and this would allow the user to catch their own exceptions by their types. </li> </ul> </section> <section id="rationale"> <h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2> Grouping several exceptions together can be done without changes to the language, simply by creating a container exception type. Trio <a class="footnote-reference brackets" href="#id20" id="id11">[2]</a> is an example of a library that has made use of this technique in its <code class="docutils literal notranslate">MultiError</code> <a class="footnote-reference brackets" href="#id27" id="id12">[9]</a> 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. Furthermore, exceptions in Python have important information attached to their <code class="docutils literal notranslate">__traceback__</code>, <code class="docutils literal notranslate">__cause__</code> and <code class="docutils literal notranslate">__context__</code> 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 the very least we would like to be able to catch an exception group only if it contains an exception of a type that we choose to handle. Exceptions of other types in the same group need to be automatically reraised, otherwise it is too easy for user code to inadvertently swallow exceptions that it is not handling. We considered whether it is possible to modify the semantics of <code class="docutils literal notranslate">except</code> for this purpose, in a backwards-compatible manner, and found that it is not. See the <a class="reference internal" href="#rejected-ideas">Rejected Ideas</a> section for more on this. The purpose of this PEP, then, is to add the <code class="docutils literal notranslate">ExceptionGroup</code> builtin type and the <code class="docutils literal notranslate">except*</code> syntax for handling exception groups in the interpreter. The desired semantics of <code class="docutils literal notranslate">except*</code> are sufficiently different from the current exception handling semantics that we are not proposing to modify the behavior of the <code class="docutils literal notranslate">except</code> keyword but rather to add the new <code class="docutils literal notranslate">except*</code> syntax. Our premise is that exception groups and <code class="docutils literal notranslate">except*</code> will be used selectively, only when they are needed. We do not expect them to become the default mechanism for exception handling. The decision to raise exception groups from a library needs to be considered carefully and regarded as an API-breaking change. We expect that this will normally be done by introducing a new API rather than modifying an existing one. </section> <section id="specification"> <h2><a class="toc-backref" href="#specification" role="doc-backlink">Specification</a></h2> <section id="exceptiongroup-and-baseexceptiongroup"> <h3><a class="toc-backref" href="#exceptiongroup-and-baseexceptiongroup" role="doc-backlink">ExceptionGroup and BaseExceptionGroup</a></h3> We propose to add two new builtin exception types: <code class="docutils literal notranslate">BaseExceptionGroup(BaseException)</code> and <code class="docutils literal notranslate">ExceptionGroup(BaseExceptionGroup, Exception)</code>. They are assignable to <code class="docutils literal notranslate">Exception.__cause__</code> and <code class="docutils literal notranslate">Exception.__context__</code>, and they can be raised and handled as any exception with <code class="docutils literal notranslate">raise ExceptionGroup(...)</code> and <code class="docutils literal notranslate">try: ... except ExceptionGroup: ...</code> or <code class="docutils literal notranslate">raise BaseExceptionGroup(...)</code> and <code class="docutils literal notranslate">try: ... except BaseExceptionGroup: ...</code>. Both have a constructor that takes two positional-only arguments: a message string and a sequence of the nested exceptions, which are exposed in the fields <code class="docutils literal notranslate">message</code> and <code class="docutils literal notranslate">exceptions</code>. For example: <code class="docutils literal notranslate">ExceptionGroup('issues', [ValueError('bad value'), TypeError('bad type')])</code>. The difference between them is that <code class="docutils literal notranslate">ExceptionGroup</code> can only wrap <code class="docutils literal notranslate">Exception</code> subclasses while <code class="docutils literal notranslate">BaseExceptionGroup</code> can wrap any <code class="docutils literal notranslate">BaseException</code> subclass. The <code class="docutils literal notranslate">BaseExceptionGroup</code> constructor inspects the nested exceptions and if they are all <code class="docutils literal notranslate">Exception</code> subclasses, it returns an <code class="docutils literal notranslate">ExceptionGroup</code> rather than a <code class="docutils literal notranslate">BaseExceptionGroup</code>. The <code class="docutils literal notranslate">ExceptionGroup</code> constructor raises a <code class="docutils literal notranslate">TypeError</code> if any of the nested exceptions is not an <code class="docutils literal notranslate">Exception</code> instance. In the rest of the document, when we refer to an exception group, we mean either an <code class="docutils literal notranslate">ExceptionGroup</code> or a <code class="docutils literal notranslate">BaseExceptionGroup</code>. When it is necessary to make the distinction, we use the class name. For brevity, we will use <code class="docutils literal notranslate">ExceptionGroup</code> in code examples that are relevant to both. Since an exception group can be nested, it represents a tree of exceptions, where the leaves are plain exceptions and each internal node represents a time at which the program grouped some unrelated exceptions into a new group and raised them together. The <code class="docutils literal notranslate">BaseExceptionGroup.subgroup(condition)</code> method gives us a way to obtain an exception group that has the same metadata (message, cause, context, traceback) as the original group, and the same nested structure of groups, but contains only those exceptions for which the condition is true: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> eg = ExceptionGroup( ... "one", ... [ ... TypeError(1), ... ExceptionGroup( ... "two", ... [TypeError(2), ValueError(3)] ... ), ... ExceptionGroup( ... "three", ... [OSError(4)] ... ) ... ] ... ) >>> import traceback >>> traceback.print_exception(eg) | ExceptionGroup: one (3 sub-exceptions) +-+---------------- 1 ---------------- | TypeError: 1 +---------------- 2 ---------------- | ExceptionGroup: two (2 sub-exceptions) +-+---------------- 1 ---------------- | TypeError: 2 +---------------- 2 ---------------- | ValueError: 3 +------------------------------------ +---------------- 3 ---------------- | ExceptionGroup: three (1 sub-exception) +-+---------------- 1 ---------------- | OSError: 4 +------------------------------------ >>> type_errors = eg.subgroup(lambda e: isinstance(e, TypeError)) >>> traceback.print_exception(type_errors) | ExceptionGroup: one (2 sub-exceptions) +-+---------------- 1 ---------------- | TypeError: 1 +---------------- 2 ---------------- | ExceptionGroup: two (1 sub-exception) +-+---------------- 1 ---------------- | TypeError: 2 +------------------------------------ >>> </pre></div> </div> The match condition is also applied to interior nodes (the exception groups), and a match causes the whole subtree rooted at this node to be included in the result. Empty nested groups are omitted from the result, as in the case of <code class="docutils literal notranslate">ExceptionGroup("three")</code> in the example above. If none of the exceptions match the condition, <code class="docutils literal notranslate">subgroup</code> returns <code class="docutils literal notranslate">None</code> rather than an empty group. The original <code class="docutils literal notranslate">eg</code> is unchanged by <code class="docutils literal notranslate">subgroup</code>, but the value returned is not necessarily a full new copy. Leaf exceptions are not copied, nor are exception groups which are fully contained in the result. When it is necessary to partition a group because the condition holds for some, but not all of its contained exceptions, a new <code class="docutils literal notranslate">ExceptionGroup</code> or <code class="docutils literal notranslate">BaseExceptionGroup</code> instance is created, while the <code class="docutils literal notranslate">__cause__</code>, <code class="docutils literal notranslate">__context__</code> and <code class="docutils literal notranslate">__traceback__</code> fields are copied by reference, so they are shared with the original <code class="docutils literal notranslate">eg</code>. If both the subgroup and its complement are needed, the <code class="docutils literal notranslate">BaseExceptionGroup.split(condition)</code> method can be used: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> type_errors, other_errors = eg.split(lambda e: isinstance(e, TypeError)) >>> traceback.print_exception(type_errors) | ExceptionGroup: one (2 sub-exceptions) +-+---------------- 1 ---------------- | TypeError: 1 +---------------- 2 ---------------- | ExceptionGroup: two (1 sub-exception) +-+---------------- 1 ---------------- | TypeError: 2 +------------------------------------ >>> traceback.print_exception(other_errors) | ExceptionGroup: one (2 sub-exceptions) +-+---------------- 1 ---------------- | ExceptionGroup: two (1 sub-exception) +-+---------------- 1 ---------------- | ValueError: 3 +------------------------------------ +---------------- 2 ---------------- | ExceptionGroup: three (1 sub-exception) +-+---------------- 1 ---------------- | OSError: 4 +------------------------------------ >>> </pre></div> </div> If a split is trivial (one side is empty), then None is returned for the other side: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> other_errors.split(lambda e: isinstance(e, SyntaxError)) (None, ExceptionGroup('one', [ ExceptionGroup('two', [ ValueError(3) ]), ExceptionGroup('three', [ OSError(4)])])) </pre></div> </div> Since splitting by exception type is a very common use case, <code class="docutils literal notranslate">subgroup</code> and <code class="docutils literal notranslate">split</code> can take an exception type or tuple of exception types and treat it as a shorthand for matching that type: <code class="docutils literal notranslate">eg.split(T)</code> divides <code class="docutils literal notranslate">eg</code> into the subgroup of leaf exceptions that match the type <code class="docutils literal notranslate">T</code>, and the subgroup of those that do not (using the same check as <code class="docutils literal notranslate">except</code> for a match). <section id="subclassing-exception-groups"> <h4><a class="toc-backref" href="#subclassing-exception-groups" role="doc-backlink">Subclassing Exception Groups</a></h4> It is possible to subclass exception groups, but when doing that it is usually necessary to specify how <code class="docutils literal notranslate">subgroup()</code> and <code class="docutils literal notranslate">split()</code> should create new instances for the matching or non-matching part of the partition. <code class="docutils literal notranslate">BaseExceptionGroup</code> exposes an instance method <code class="docutils literal notranslate">derive(self, excs)</code> which is called whenever <code class="docutils literal notranslate">subgroup</code> and <code class="docutils literal notranslate">split</code> need to create a new exception group. The parameter <code class="docutils literal notranslate">excs</code> is the sequence of exceptions to include in the new group. Since <code class="docutils literal notranslate">derive</code> has access to self, it can copy data from it to the new object. For example, if we need an exception group subclass that has an additional error code field, we can do this: <div class="highlight-default notranslate"><div class="highlight"><pre>class MyExceptionGroup(ExceptionGroup): def __new__(cls, message, excs, errcode): obj = super().__new__(cls, message, excs) obj.errcode = errcode return obj def derive(self, excs): return MyExceptionGroup(self.message, excs, self.errcode) </pre></div> </div> Note that we override <code class="docutils literal notranslate">__new__</code> rather than <code class="docutils literal notranslate">__init__</code>; this is because <code class="docutils literal notranslate">BaseExceptionGroup.__new__</code> needs to inspect the constructor arguments, and its signature is different from that of the subclass. Note also that our <code class="docutils literal notranslate">derive</code> function does not copy the <code class="docutils literal notranslate">__context__</code>, <code class="docutils literal notranslate">__cause__</code> and <code class="docutils literal notranslate">__traceback__</code> fields, because <code class="docutils literal notranslate">subgroup</code> and <code class="docutils literal notranslate">split</code> do that for us. With the class defined above, we have the following: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> eg = MyExceptionGroup("eg", [TypeError(1), ValueError(2)], 42) >>> >>> match, rest = eg.split(ValueError) >>> print(f'match: {match!r}: {match.errcode}') match: MyExceptionGroup('eg', [ValueError(2)], 42): 42 >>> print(f'rest: {rest!r}: {rest.errcode}') rest: MyExceptionGroup('eg', [TypeError(1)], 42): 42 >>> </pre></div> </div> If we do not override <code class="docutils literal notranslate">derive</code>, then split calls the one defined on <code class="docutils literal notranslate">BaseExceptionGroup</code>, which returns an instance of <code class="docutils literal notranslate">ExceptionGroup</code> if all contained exceptions are of type <code class="docutils literal notranslate">Exception</code>, and <code class="docutils literal notranslate">BaseExceptionGroup</code> otherwise. For example: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> class MyExceptionGroup(BaseExceptionGroup): ... pass ... >>> eg = MyExceptionGroup("eg", [ValueError(1), KeyboardInterrupt(2)]) >>> match, rest = eg.split(ValueError) >>> print(f'match: {match!r}') match: ExceptionGroup('eg', [ValueError(1)]) >>> print(f'rest: {rest!r}') rest: BaseExceptionGroup('eg', [KeyboardInterrupt(2)]) >>> </pre></div> </div> </section> <section id="the-traceback-of-an-exception-group"> <h4><a class="toc-backref" href="#the-traceback-of-an-exception-group" role="doc-backlink">The Traceback of an Exception Group</a></h4> For regular exceptions, the traceback represents a simple path of frames, from the frame in which the exception was raised to the frame in which it was caught or, if it hasn’t been caught yet, the frame that the program’s execution is currently in. The list is constructed by the interpreter, which appends any frame from which it exits to the traceback of the ‘current exception’ if one exists. To support efficient appends, the links in a traceback’s list of frames are from the oldest to the newest frame. Appending a new frame is then simply a matter of inserting a new head to the linked list referenced from the exception’s <code class="docutils literal notranslate">__traceback__</code> field. Crucially, the traceback’s frame list is immutable in the sense that frames only need to be added at the head, and never need to be removed. We do not need to make any changes to this data structure. The <code class="docutils literal notranslate">__traceback__</code> field of the exception group instance represents the path that the contained exceptions travelled through together after being joined into the group, and the same field on each of the nested exceptions represents the path through which this exception arrived at the frame of the merge. What we do need to change is any code that interprets and displays tracebacks, because it now needs to continue into tracebacks of nested exceptions, as in the following example: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> def f(v): ... try: ... raise ValueError(v) ... except ValueError as e: ... return e ... >>> try: ... raise ExceptionGroup("one", [f(1)]) ... except ExceptionGroup as e: ... eg = e ... >>> raise ExceptionGroup("two", [f(2), eg]) + Exception Group Traceback (most recent call last): | File "<stdin>", line 1, in <module> | ExceptionGroup: two (2 sub-exceptions) +-+---------------- 1 ---------------- | Traceback (most recent call last): | File "<stdin>", line 3, in f | ValueError: 2 +---------------- 2 ---------------- | Exception Group Traceback (most recent call last): | File "<stdin>", line 2, in <module> | ExceptionGroup: one (1 sub-exception) +-+---------------- 1 ---------------- | Traceback (most recent call last): | File "<stdin>", line 3, in f | ValueError: 1 +------------------------------------ >>> </pre></div> </div> </section> <section id="handling-exception-groups"> <h4><a class="toc-backref" href="#handling-exception-groups" role="doc-backlink">Handling Exception Groups</a></h4> We expect that when programs catch and handle exception groups, they will typically either query to check if it has leaf exceptions for which some condition holds (using <code class="docutils literal notranslate">subgroup</code> or <code class="docutils literal notranslate">split</code>) or format the exception (using the <code class="docutils literal notranslate">traceback</code> module’s methods). It is less likely to be useful to iterate over the individual leaf exceptions. To see why, suppose that an application caught an exception group raised by an <code class="docutils literal notranslate">asyncio.gather()</code> call. At this stage, the context for each specific exception is lost. Any recovery for this exception should have been performed before it was grouped with other exceptions <a class="footnote-reference brackets" href="#id28" id="id13">[10]</a>. Furthermore, the application is likely to react in the same way to any number of instances of a certain exception type, so it is more likely that we will want to know whether <code class="docutils literal notranslate">eg.subgroup(T)</code> is None or not, than we are to be interested in the number of <code class="docutils literal notranslate">Ts</code> in <code class="docutils literal notranslate">eg</code>. However, there are situations where it is necessary to inspect the individual leaf exceptions. For example, suppose that we have an exception group <code class="docutils literal notranslate">eg</code> and that we want to log the <code class="docutils literal notranslate">OSErrors</code> that have a specific error code and reraise everything else. We can do this by passing a function with side effects to <code class="docutils literal notranslate">subgroup</code>, as follows: <div class="highlight-default notranslate"><div class="highlight"><pre>def log_and_ignore_ENOENT(err): if isinstance(err, OSError) and err.errno == ENOENT: log(err) return False else: return True try: . . . except ExceptionGroup as eg: eg = eg.subgroup(log_and_ignore_ENOENT) if eg is not None: raise eg </pre></div> </div> In the previous example, when <code class="docutils literal notranslate">log_and_ignore_ENOENT</code> is invoked on a leaf exception, only part of this exception’s traceback is accessible – the part referenced from its <code class="docutils literal notranslate">__traceback__</code> field. If we need the full traceback, we need to look at the concatenation of the tracebacks of the exceptions on the path from the root to this leaf. We can get that with direct iteration, recursively, as follows: <div class="highlight-default notranslate"><div class="highlight"><pre>def leaf_generator(exc, tbs=None): if tbs is None: tbs = [] tbs.append(exc.__traceback__) if isinstance(exc, BaseExceptionGroup): for e in exc.exceptions: yield from leaf_generator(e, tbs) else: # exc is a leaf exception and its traceback # is the concatenation of the traceback # segments in tbs. # Note: the list returned (tbs) is reused in each iteration # through the generator. Make a copy if your use case holds # on to it beyond the current iteration or mutates its contents. yield exc, tbs tbs.pop() </pre></div> </div> We can then process the full tracebacks of the leaf exceptions: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> import traceback >>> >>> def g(v): ... try: ... raise ValueError(v) ... except Exception as e: ... return e ... >>> def f(): ... raise ExceptionGroup("eg", [g(1), g(2)]) ... >>> try: ... f() ... except BaseException as e: ... eg = e ... >>> for (i, (exc, tbs)) in enumerate(leaf_generator(eg)): ... print(f"\n=== Exception #{i+1}:") ... traceback.print_exception(exc) ... print(f"The complete traceback for Exception #{i+1}:") ... for tb in tbs: ... traceback.print_tb(tb) ... === Exception #1: Traceback (most recent call last): File "<stdin>", line 3, in g ValueError: 1 The complete traceback for Exception #1 File "<stdin>", line 2, in <module> File "<stdin>", line 2, in f File "<stdin>", line 3, in g === Exception #2: Traceback (most recent call last): File "<stdin>", line 3, in g ValueError: 2 The complete traceback for Exception #2: File "<stdin>", line 2, in <module> File "<stdin>", line 2, in f File "<stdin>", line 3, in g >>> </pre></div> </div> </section> </section> <section id="except"> <h3><a class="toc-backref" href="#except" role="doc-backlink">except*</a></h3> We are proposing to introduce a new variant of the <code class="docutils literal notranslate">try..except</code> syntax to simplify working with exception groups. The <code class="docutils literal notranslate">*</code> symbol indicates that multiple exceptions can be handled by each <code class="docutils literal notranslate">except*</code> clause: <div class="highlight-default notranslate"><div class="highlight"><pre>try: ... except* SpamError: ... except* FooError as e: ... except* (BarError, BazError) as e: ... </pre></div> </div> In a traditional <code class="docutils literal notranslate">try-except</code> statement there is only one exception to handle, so the body of at most one <code class="docutils literal notranslate">except</code> clause executes; the first one that matches the exception. With the new syntax, an <code class="docutils literal notranslate">except*</code> clause can match a subgroup of the exception group that was raised, while the remaining part is matched by following <code class="docutils literal notranslate">except*</code> clauses. In other words, a single exception group can cause several <code class="docutils literal notranslate">except*</code> clauses to execute, but each such clause executes at most once (for all matching exceptions from the group) and each exception is either handled by exactly one clause (the first one that matches its type) or is reraised at the end. The manner in which each exception is handled by a <code class="docutils literal notranslate">try-except*</code> block is independent of any other exceptions in the group. For example, suppose that the body of the <code class="docutils literal notranslate">try</code> block above raises <code class="docutils literal notranslate">eg = ExceptionGroup('msg', [FooError(1), FooError(2), BazError()])</code>. The <code class="docutils literal notranslate">except*</code> clauses are evaluated in order by calling <code class="docutils literal notranslate">split</code> on the <code class="docutils literal notranslate">unhandled</code> exception group, which is initially equal to <code class="docutils literal notranslate">eg</code> and then shrinks as exceptions are matched and extracted from it. In the first <code class="docutils literal notranslate">except*</code> clause, <code class="docutils literal notranslate">unhandled.split(SpamError)</code> returns <code class="docutils literal notranslate">(None, unhandled)</code> so the body of this block is not executed and <code class="docutils literal notranslate">unhandled</code> is unchanged. For the second block, <code class="docutils literal notranslate">unhandled.split(FooError)</code> returns a non-trivial split <code class="docutils literal notranslate">(match, rest)</code> with <code class="docutils literal notranslate">match = ExceptionGroup('msg', [FooError(1), FooError(2)])</code> and <code class="docutils literal notranslate">rest = ExceptionGroup('msg', [BazError()])</code>. The body of this <code class="docutils literal notranslate">except*</code> block is executed, with the value of <code class="docutils literal notranslate">e</code> and <code class="docutils literal notranslate">sys.exc_info()</code> set to <code class="docutils literal notranslate">match</code>. Then, <code class="docutils literal notranslate">unhandled</code> is set to <code class="docutils literal notranslate">rest</code>. Finally, the third block matches the remaining exception so it is executed with <code class="docutils literal notranslate">e</code> and <code class="docutils literal notranslate">sys.exc_info()</code> set to <code class="docutils literal notranslate">ExceptionGroup('msg', [BazError()])</code>. Exceptions are matched using a subclass check. For example: <div class="highlight-default notranslate"><div class="highlight"><pre>try: low_level_os_operation() except* OSError as eg: for e in eg.exceptions: print(type(e).__name__) </pre></div> </div> could output: <div class="highlight-default notranslate"><div class="highlight"><pre>BlockingIOError ConnectionRefusedError OSError InterruptedError BlockingIOError </pre></div> </div> The order of <code class="docutils literal notranslate">except*</code> clauses is significant just like with the regular <code class="docutils literal notranslate">try..except</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> try: ... raise ExceptionGroup("problem", [BlockingIOError()]) ... except* OSError as e: # Would catch the error ... print(repr(e)) ... except* BlockingIOError: # Would never run ... print('never') ... ExceptionGroup('problem', [BlockingIOError()]) </pre></div> </div> <section id="recursive-matching"> <h4><a class="toc-backref" href="#recursive-matching" role="doc-backlink">Recursive Matching</a></h4> The matching of <code class="docutils literal notranslate">except*</code> clauses against an exception group is performed recursively, using the <code class="docutils literal notranslate">split()</code> method: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> try: ... raise ExceptionGroup( ... "eg", ... [ ... ValueError('a'), ... TypeError('b'), ... ExceptionGroup( ... "nested", ... [TypeError('c'), KeyError('d')]) ... ] ... ) ... except* TypeError as e1: ... print(f'e1 = {e1!r}') ... except* Exception as e2: ... print(f'e2 = {e2!r}') ... e1 = ExceptionGroup('eg', [TypeError('b'), ExceptionGroup('nested', [TypeError('c')])]) e2 = ExceptionGroup('eg', [ValueError('a'), ExceptionGroup('nested', [KeyError('d')])]) >>> </pre></div> </div> </section> <section id="unmatched-exceptions"> <h4><a class="toc-backref" href="#unmatched-exceptions" role="doc-backlink">Unmatched Exceptions</a></h4> If not all exceptions in an exception group were matched by the <code class="docutils literal notranslate">except*</code> clauses, the remaining part of the group is propagated on: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> try: ... try: ... raise ExceptionGroup( ... "msg", [ ... ValueError('a'), TypeError('b'), ... TypeError('c'), KeyError('e') ... ] ... ) ... except* ValueError as e: ... print(f'got some ValueErrors: {e!r}') ... except* TypeError as e: ... print(f'got some TypeErrors: {e!r}') ... except ExceptionGroup as e: ... print(f'propagated: {e!r}') ... got some ValueErrors: ExceptionGroup('msg', [ValueError('a')]) got some TypeErrors: ExceptionGroup('msg', [TypeError('b'), TypeError('c')]) propagated: ExceptionGroup('msg', [KeyError('e')]) >>> </pre></div> </div> </section> <section id="naked-exceptions"> <h4><a class="toc-backref" href="#naked-exceptions" role="doc-backlink">Naked Exceptions</a></h4> If the exception raised inside the <code class="docutils literal notranslate">try</code> body is not of type <code class="docutils literal notranslate">ExceptionGroup</code> or <code class="docutils literal notranslate">BaseExceptionGroup</code>, we call it a <code class="docutils literal notranslate">naked</code> exception. If its type matches one of the <code class="docutils literal notranslate">except*</code> clauses, it is caught and wrapped by an <code class="docutils literal notranslate">ExceptionGroup</code> (or <code class="docutils literal notranslate">BaseExceptionGroup</code> if it is not an <code class="docutils literal notranslate">Exception</code> subclass) with an empty message string. This is to make the type of <code class="docutils literal notranslate">e</code> consistent and statically known: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> try: ... raise BlockingIOError ... except* OSError as e: ... print(repr(e)) ... ExceptionGroup('', [BlockingIOError()]) </pre></div> </div> However, if a naked exception is not caught, it propagates in its original naked form: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> try: ... try: ... raise ValueError(12) ... except* TypeError as e: ... print('never') ... except ValueError as e: ... print(f'caught ValueError: {e!r}') ... caught ValueError: ValueError(12) >>> </pre></div> </div> </section> <section id="raising-exceptions-in-an-except-block"> <h4><a class="toc-backref" href="#raising-exceptions-in-an-except-block" role="doc-backlink">Raising exceptions in an <code class="docutils literal notranslate">except*</code> block</a></h4> In a traditional <code class="docutils literal notranslate">except</code> block, there are two ways to raise exceptions: <code class="docutils literal notranslate">raise e</code> to explicitly raise an exception object <code class="docutils literal notranslate">e</code>, or naked <code class="docutils literal notranslate">raise</code> to reraise the ‘current exception’. When <code class="docutils literal notranslate">e</code> is the current exception, the two forms are not equivalent because a reraise does not add the current frame to the stack: <div class="highlight-default notranslate"><div class="highlight"><pre>def foo(): | def foo(): try: | try: 1 / 0 | 1 / 0 except ZeroDivisionError as e: | except ZeroDivisionError: raise e | raise | foo() | foo() | Traceback (most recent call last): | Traceback (most recent call last): File "/Users/guido/a.py", line 7 | File "/Users/guido/b.py", line 7 foo() | foo() File "/Users/guido/a.py", line 5 | File "/Users/guido/b.py", line 3 raise e | 1/0 File "/Users/guido/a.py", line 3 | ZeroDivisionError: division by zero 1/0 | ZeroDivisionError: division by zero | </pre></div> </div> This holds for exception groups as well, but the situation is now more complex because there can be exceptions raised and reraised from multiple <code class="docutils literal notranslate">except*</code> clauses, as well as unhandled exceptions that need to propagate. The interpreter needs to combine all those exceptions into a result, and raise that. The reraised exceptions and the unhandled exceptions are subgroups of the original group, and share its metadata (cause, context, traceback). On the other hand, each of the explicitly raised exceptions has its own metadata - the traceback contains the line from which it was raised, its cause is whatever it may have been explicitly chained to, and its context is the value of <code class="docutils literal notranslate">sys.exc_info()</code> in the <code class="docutils literal notranslate">except*</code> clause of the raise. In the aggregated exception group, the reraised and unhandled exceptions have the same relative structure as in the original exception, as if they were split off together in one <code class="docutils literal notranslate">subgroup</code> call. For example, in the snippet below the inner <code class="docutils literal notranslate">try-except*</code> block raises an <code class="docutils literal notranslate">ExceptionGroup</code> that contains all <code class="docutils literal notranslate">ValueErrors</code> and <code class="docutils literal notranslate">TypeErrors</code> merged back into the same shape they had in the original <code class="docutils literal notranslate">ExceptionGroup</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> try: ... try: ... raise ExceptionGroup( ... "eg", ... [ ... ValueError(1), ... TypeError(2), ... OSError(3), ... ExceptionGroup( ... "nested", ... [OSError(4), TypeError(5), ValueError(6)]) ... ] ... ) ... except* ValueError as e: ... print(f'*ValueError: {e!r}') ... raise ... except* OSError as e: ... print(f'*OSError: {e!r}') ... except ExceptionGroup as e: ... print(repr(e)) ... *ValueError: ExceptionGroup('eg', [ValueError(1), ExceptionGroup('nested', [ValueError(6)])]) *OSError: ExceptionGroup('eg', [OSError(3), ExceptionGroup('nested', [OSError(4)])]) ExceptionGroup('eg', [ValueError(1), TypeError(2), ExceptionGroup('nested', [TypeError(5), ValueError(6)])]) >>> </pre></div> </div> When exceptions are raised explicitly, they are independent of the original exception group, and cannot be merged with it (they have their own cause, context and traceback). Instead, they are combined into a new <code class="docutils literal notranslate">ExceptionGroup</code> (or <code class="docutils literal notranslate">BaseExceptionGroup</code>), which also contains the reraised/unhandled subgroup described above. In the following example, the <code class="docutils literal notranslate">ValueErrors</code> were raised so they are in their own <code class="docutils literal notranslate">ExceptionGroup</code>, while the <code class="docutils literal notranslate">OSErrors</code> were reraised so they were merged with the unhandled <code class="docutils literal notranslate">TypeErrors</code>. <div class="highlight-default notranslate"><div class="highlight"><pre>>>> try: ... raise ExceptionGroup( ... "eg", ... [ ... ValueError(1), ... TypeError(2), ... OSError(3), ... ExceptionGroup( ... "nested", ... [OSError(4), TypeError(5), ValueError(6)]) ... ] ... ) ... except* ValueError as e: ... print(f'*ValueError: {e!r}') ... raise e ... except* OSError as e: ... print(f'*OSError: {e!r}') ... raise ... *ValueError: ExceptionGroup('eg', [ValueError(1), ExceptionGroup('nested', [ValueError(6)])]) *OSError: ExceptionGroup('eg', [OSError(3), ExceptionGroup('nested', [OSError(4)])]) | ExceptionGroup: (2 sub-exceptions) +-+---------------- 1 ---------------- | Exception Group Traceback (most recent call last): | File "<stdin>", line 15, in <module> | File "<stdin>", line 2, in <module> | ExceptionGroup: eg (2 sub-exceptions) +-+---------------- 1 ---------------- | ValueError: 1 +---------------- 2 ---------------- | ExceptionGroup: nested (1 sub-exception) +-+---------------- 1 ---------------- | ValueError: 6 +------------------------------------ +---------------- 2 ---------------- | Exception Group Traceback (most recent call last): | File "<stdin>", line 2, in <module> | ExceptionGroup: eg (3 sub-exceptions) +-+---------------- 1 ---------------- | TypeError: 2 +---------------- 2 ---------------- | OSError: 3 +---------------- 3 ---------------- | ExceptionGroup: nested (2 sub-exceptions) +-+---------------- 1 ---------------- | OSError: 4 +---------------- 2 ---------------- | TypeError: 5 +------------------------------------ >>> </pre></div> </div> </section> <section id="chaining"> <h4><a class="toc-backref" href="#chaining" role="doc-backlink">Chaining</a></h4> Explicitly raised exception groups are chained as with any exceptions. The following example shows how part of <code class="docutils literal notranslate">ExceptionGroup</code> “one” became the context for <code class="docutils literal notranslate">ExceptionGroup</code> “two”, while the other part was combined with it into the new <code class="docutils literal notranslate">ExceptionGroup</code>. <div class="highlight-default notranslate"><div class="highlight"><pre>>>> try: ... raise ExceptionGroup("one", [ValueError('a'), TypeError('b')]) ... except* ValueError: ... raise ExceptionGroup("two", [KeyError('x'), KeyError('y')]) ... | ExceptionGroup: (2 sub-exceptions) +-+---------------- 1 ---------------- | Exception Group Traceback (most recent call last): | File "<stdin>", line 2, in <module> | ExceptionGroup: one (1 sub-exception) +-+---------------- 1 ---------------- | ValueError: a +------------------------------------ | | During handling of the above exception, another exception occurred: | | Exception Group Traceback (most recent call last): | File "<stdin>", line 4, in <module> | ExceptionGroup: two (2 sub-exceptions) +-+---------------- 1 ---------------- | KeyError: 'x' +---------------- 2 ---------------- | KeyError: 'y' +------------------------------------ +---------------- 2 ---------------- | Exception Group Traceback (most recent call last): | File "<stdin>", line 2, in <module> | ExceptionGroup: one (1 sub-exception) +-+---------------- 1 ---------------- | TypeError: b +------------------------------------ >>> </pre></div> </div> </section> <section id="raising-new-exceptions"> <h4><a class="toc-backref" href="#raising-new-exceptions" role="doc-backlink">Raising New Exceptions</a></h4> In the previous examples the explicit raises were of the exceptions that were caught, so for completion we show a new exception being raised, with chaining: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> try: ... raise TypeError('bad type') ... except* TypeError as e: ... raise ValueError('bad value') from e ... | ExceptionGroup: (1 sub-exception) +-+---------------- 1 ---------------- | Traceback (most recent call last): | File "<stdin>", line 2, in <module> | TypeError: bad type +------------------------------------ The above exception was the direct cause of the following exception: Traceback (most recent call last): File "<stdin>", line 4, in <module> ValueError: bad value >>> </pre></div> </div> Note that exceptions raised in one <code class="docutils literal notranslate">except*</code> clause are not eligible to match other clauses from the same <code class="docutils literal notranslate">try</code> statement: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> try: ... raise TypeError(1) ... except* TypeError: ... raise ValueError(2) from None # <- not caught in the next clause ... except* ValueError: ... print('never') ... Traceback (most recent call last): File "<stdin>", line 4, in <module> ValueError: 2 >>> </pre></div> </div> Raising a new instance of a naked exception does not cause this exception to be wrapped by an exception group. Rather, the exception is raised as is, and if it needs to be combined with other propagated exceptions, it becomes a direct child of the new exception group created for that: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> try: ... raise ExceptionGroup("eg", [ValueError('a')]) ... except* ValueError: ... raise KeyError('x') ... | ExceptionGroup: (1 sub-exception) +-+---------------- 1 ---------------- | Exception Group Traceback (most recent call last): | File "<stdin>", line 2, in <module> | ExceptionGroup: eg (1 sub-exception) +-+---------------- 1 ---------------- | ValueError: a +------------------------------------ | | During handling of the above exception, another exception occurred: | | Traceback (most recent call last): | File "<stdin>", line 4, in <module> | KeyError: 'x' +------------------------------------ >>> >>> try: ... raise ExceptionGroup("eg", [ValueError('a'), TypeError('b')]) ... except* ValueError: ... raise KeyError('x') ... | ExceptionGroup: (2 sub-exceptions) +-+---------------- 1 ---------------- | Exception Group Traceback (most recent call last): | File "<stdin>", line 2, in <module> | ExceptionGroup: eg (1 sub-exception) +-+---------------- 1 ---------------- | ValueError: a +------------------------------------ | | During handling of the above exception, another exception occurred: | | Traceback (most recent call last): | File "<stdin>", line 4, in <module> | KeyError: 'x' +---------------- 2 ---------------- | Exception Group Traceback (most recent call last): | File "<stdin>", line 2, in <module> | ExceptionGroup: eg (1 sub-exception) +-+---------------- 1 ---------------- | TypeError: b +------------------------------------ >>> </pre></div> </div> Finally, as an example of how the proposed semantics can help us work effectively with exception groups, the following code ignores all <code class="docutils literal notranslate">EPIPE</code> OS errors, while letting all other exceptions propagate. <div class="highlight-default notranslate"><div class="highlight"><pre>try: low_level_os_operation() except* OSError as errors: exc = errors.subgroup(lambda e: e.errno != errno.EPIPE) if exc is not None: raise exc from None </pre></div> </div> </section> <section id="caught-exception-objects"> <h4><a class="toc-backref" href="#caught-exception-objects" role="doc-backlink">Caught Exception Objects</a></h4> It is important to point out that the exception group bound to <code class="docutils literal notranslate">e</code> in an <code class="docutils literal notranslate">except*</code> clause is an ephemeral object. Raising it via <code class="docutils literal notranslate">raise</code> or <code class="docutils literal notranslate">raise e</code> will not cause changes to the overall shape of the original exception group. Any modifications to <code class="docutils literal notranslate">e</code> will likely be lost: <div class="highlight-default notranslate"><div class="highlight"><pre>>>> eg = ExceptionGroup("eg", [TypeError(12)]) >>> eg.foo = 'foo' >>> try: ... raise eg ... except* TypeError as e: ... e.foo = 'bar' ... # ^----------- ``e`` is an ephemeral object that might get >>> # destroyed after the ``except*`` clause. >>> eg.foo 'foo' </pre></div> </div> </section> <section id="forbidden-combinations"> <h4><a class="toc-backref" href="#forbidden-combinations" role="doc-backlink">Forbidden Combinations</a></h4> It is not possible to use both traditional <code class="docutils literal notranslate">except</code> blocks and the new <code class="docutils literal notranslate">except*</code> clauses in the same <code class="docutils literal notranslate">try</code> statement. The following is a <code class="docutils literal notranslate">SyntaxError</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>try: ... except ValueError: pass except* CancelledError: # <- SyntaxError: pass # combining ``except`` and ``except*`` # is prohibited </pre></div> </div> It is possible to catch the <code class="docutils literal notranslate">ExceptionGroup</code> and <code class="docutils literal notranslate">BaseExceptionGroup</code> types with <code class="docutils literal notranslate">except</code>, but not with <code class="docutils literal notranslate">except*</code> because the latter is ambiguous: <div class="highlight-default notranslate"><div class="highlight"><pre>try: ... except ExceptionGroup: # <- This works pass try: ... except* ExceptionGroup: # <- Runtime error pass try: ... except* (TypeError, ExceptionGroup): # <- Runtime error pass </pre></div> </div> An empty “match anything” <code class="docutils literal notranslate">except*</code> block is not supported as its meaning may be confusing: <div class="highlight-default notranslate"><div class="highlight"><pre>try: ... except*: # <- SyntaxError pass </pre></div> </div> <code class="docutils literal notranslate">continue</code>, <code class="docutils literal notranslate">break</code>, and <code class="docutils literal notranslate">return</code> are disallowed in <code class="docutils literal notranslate">except*</code> clauses, causing a <code class="docutils literal notranslate">SyntaxError</code>. This is because the exceptions in an <code class="docutils literal notranslate">ExceptionGroup</code> are assumed to be independent, and the presence or absence of one of them should not impact handling of the others, as could happen if we allow an <code class="docutils literal notranslate">except*</code> clause to change the way control flows through other clauses. </section> </section> </section> <section id="backwards-compatibility"> <h2><a class="toc-backref" href="#backwards-compatibility" role="doc-backlink">Backwards Compatibility</a></h2> Backwards compatibility was a requirement of our design, and the changes we propose in this PEP will not break any existing code: <ul class="simple"> <li>The addition of the new builtin exception types <code class="docutils literal notranslate">ExceptionGroup</code> and <code class="docutils literal notranslate">BaseExceptionGroup</code> does not impact existing programs. The way that existing exceptions are handled and displayed does not change in any way.</li> <li>The behaviour of <code class="docutils literal notranslate">except</code> is unchanged so existing code will continue to work. Programs will only be impacted by the changes proposed in this PEP once they begin to use exception groups and <code class="docutils literal notranslate">except*</code>.</li> <li>An important concern was that <code class="docutils literal notranslate">except Exception:</code> will continue to catch almost all exceptions, and by making <code class="docutils literal notranslate">ExceptionGroup</code> extend <code class="docutils literal notranslate">Exception</code> we ensured that this will be the case. <code class="docutils literal notranslate">BaseExceptionGroups</code> will not be caught, which is appropriate because they include exceptions that would not have been caught by <code class="docutils literal notranslate">except Exception</code>.</li> </ul> Once programs begin to use these features, there will be migration issues to consider: <ul class="simple"> <li>An <code class="docutils literal notranslate">except T:</code> clause that wraps code which is now potentially raising an exception group may need to become <code class="docutils literal notranslate">except* T:</code>, and its body may need to be updated. This means that raising an exception group is an API-breaking change and will likely be done in new APIs rather than added to existing ones.</li> <li>Libraries that need to support older Python versions will not be able to use <code class="docutils literal notranslate">except*</code> or raise exception groups.</li> </ul> </section> <section id="how-to-teach-this"> <h2><a class="toc-backref" href="#how-to-teach-this" role="doc-backlink">How to Teach This</a></h2> Exception groups and <code class="docutils literal notranslate">except*</code> will be documented as part of the language standard. Libraries that raise exception groups such as <code class="docutils literal notranslate">asyncio</code> will need to specify this in their documentation and clarify which API calls need to be wrapped with <code class="docutils literal notranslate">try-except*</code> rather than <code class="docutils literal notranslate">try-except</code>. </section> <section id="reference-implementation"> <h2><a class="toc-backref" href="#reference-implementation" role="doc-backlink">Reference Implementation</a></h2> We developed these concepts (and the examples for this PEP) with the help of the reference implementation <a class="footnote-reference brackets" href="#id29" id="id14">[11]</a>. It has the builtin <code class="docutils literal notranslate">ExceptionGroup</code> along with the changes to the traceback formatting code, in addition to the grammar, compiler and interpreter changes required to support <code class="docutils literal notranslate">except*</code>. <code class="docutils literal notranslate">BaseExceptionGroup</code> will be added soon. Two opcodes were added: one implements the exception type match check via <code class="docutils literal notranslate">ExceptionGroup.split()</code>, and the other is used at the end of a <code class="docutils literal notranslate">try-except</code> construct to merge all unhandled, raised and reraised exceptions (if any). The raised/reraised exceptions are collected in a list on the runtime stack. For this purpose, the body of each <code class="docutils literal notranslate">except*</code> clause is wrapped in a traditional <code class="docutils literal notranslate">try-except</code> which captures any exceptions raised. Both raised and reraised exceptions are collected in the same list. When the time comes to merge them into a result, the raised and reraised exceptions are distinguished by comparing their metadata fields (context, cause, traceback) with those of the originally raised exception. As mentioned above, the reraised exceptions have the same metadata as the original, while the raised ones do not. </section> <section id="rejected-ideas"> <h2><a class="toc-backref" href="#rejected-ideas" role="doc-backlink">Rejected Ideas</a></h2> <section id="make-exception-groups-iterable"> <h3><a class="toc-backref" href="#make-exception-groups-iterable" role="doc-backlink">Make Exception Groups Iterable</a></h3> We considered making exception groups iterable, so that <code class="docutils literal notranslate">list(eg)</code> would produce a flattened list of the leaf exceptions contained in the group. We decided that this would not be a sound API, because the metadata (cause, context and traceback) of the individual exceptions in a group is incomplete and this could create problems. Furthermore, as we explained in the <a class="reference internal" href="#handling-exception-groups">Handling Exception Groups</a> section, we find it unlikely that iteration over leaf exceptions will have many use cases. 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 in the future add that utility to the standard library or even make exception groups iterable. </section> <section id="make-exceptiongroup-extend-baseexception"> <h3><a class="toc-backref" href="#make-exceptiongroup-extend-baseexception" role="doc-backlink">Make <code class="docutils literal notranslate">ExceptionGroup</code> Extend <code class="docutils literal notranslate">BaseException</code></a></h3> We considered making <code class="docutils literal notranslate">ExceptionGroup</code> subclass only <code class="docutils literal notranslate">BaseException</code>, and not <code class="docutils literal notranslate">Exception</code>. 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 <code class="docutils literal notranslate">ExceptionGroup</code> 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 <code class="docutils literal notranslate">except Exception</code> will not inadvertently swallow it. This would have been consistent with the way <code class="docutils literal notranslate">except T:</code> does not catch exception groups that contain <code class="docutils literal notranslate">T</code> for all other types, and would help contain <code class="docutils literal notranslate">ExceptionGroups</code> to the parts of the program in which they are supposed to appear. However, it was clear from the public discussion that <code class="docutils literal notranslate">T=Exception</code> is a special case, and there are developers who feel strongly that <code class="docutils literal notranslate">except Exception:</code> should catch “almost everything”, including exception groups. This is why we decided to make <code class="docutils literal notranslate">ExceptionGroup</code> a subclass of <code class="docutils literal notranslate">Exception</code>. </section> <section id="make-it-impossible-to-wrap-baseexceptions-in-an-exception-group"> <h3><a class="toc-backref" href="#make-it-impossible-to-wrap-baseexceptions-in-an-exception-group" role="doc-backlink">Make it Impossible to Wrap <code class="docutils literal notranslate">BaseExceptions</code> in an Exception Group</a></h3> A consequence of the decision to make <code class="docutils literal notranslate">ExceptionGroup</code> extend <code class="docutils literal notranslate">Exception</code> is that <code class="docutils literal notranslate">ExceptionGroup</code> should not wrap <code class="docutils literal notranslate">BaseExceptions</code> like <code class="docutils literal notranslate">KeyboardInterrupt</code>, as they are not currently caught by <code class="docutils literal notranslate">except Exception:</code>. We considered the option of simply making it impossible to wrap <code class="docutils literal notranslate">BaseExceptions</code>, but eventually decided to make it possible through the <code class="docutils literal notranslate">BaseExceptionGroup</code> type, which extends <code class="docutils literal notranslate">BaseException</code> rather than <code class="docutils literal notranslate">Exception</code>. Making this possible adds flexibility to the language and leaves it for the programmer to weigh the benefit of wrapping <code class="docutils literal notranslate">BaseExceptions</code> rather than propagating them in their naked form while discarding any other exceptions. </section> <section id="traceback-representation"> <h3><a class="toc-backref" href="#traceback-representation" role="doc-backlink">Traceback Representation</a></h3> We considered options for adapting the traceback data structure to represent trees, but it became apparent that a traceback tree is not meaningful once separated from the exceptions it refers to. While a simple-path traceback can be attached to any exception by a <code class="docutils literal notranslate">with_traceback()</code> call, it is hard to imagine a case where it makes sense to assign a traceback tree to an exception group. Furthermore, a useful display of the traceback includes information about the nested exceptions. For these reasons we decided that it is best to leave the traceback mechanism as it is and modify the traceback display code. </section> <section id="extend-except-to-handle-exception-groups"> <h3><a class="toc-backref" href="#extend-except-to-handle-exception-groups" role="doc-backlink">Extend <code class="docutils literal notranslate">except</code> to Handle Exception Groups</a></h3> We considered extending the semantics of <code class="docutils literal notranslate">except</code> to handle exception groups, instead of introducing <code class="docutils literal notranslate">except*</code>. There were two backwards compatibility concerns with this. The first is the type of the caught exception. Consider this example: <div class="highlight-default notranslate"><div class="highlight"><pre>try: . . . except OSError as err: if err.errno != ENOENT: raise </pre></div> </div> If the value assigned to err is an exception group containing all of the <code class="docutils literal notranslate">OSErrors</code> that were raised, then the attribute access <code class="docutils literal notranslate">err.errno</code> no longer works. So we would need to execute the body of the <code class="docutils literal notranslate">except</code> clause multiple times, once for each exception in the group. However, this too is a potentially breaking change because at the moment we write <code class="docutils literal notranslate">except</code> 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. The idea of making <code class="docutils literal notranslate">except</code> iterate over the leaf exceptions of an exception group is at the heart of an <a class="reference external" href="https://discuss.python.org/t/flat-exception-groups-alternative-to-pep-654/10433">alternative proposal to this PEP by Nathaniel J. Smith</a>, and the discussion about that proposal further elaborates on the pitfalls of changing <code class="docutils literal notranslate">except</code> semantics in a mature language like Python, as well as deviating from the semantics that parallel constructs have in other languages. Another option that came up in the public discussion was to add <code class="docutils literal notranslate">except*</code>, but also make <code class="docutils literal notranslate">except</code> treat <code class="docutils literal notranslate">ExceptionGroups</code> as a special case. <code class="docutils literal notranslate">except</code> would then do something along the lines of extracting one exception of matching type from the group in order to handle it (while discarding all the other exceptions in the group). The motivation behind these suggestions was to make the adoption of exception groups safer, in that <code class="docutils literal notranslate">except T</code> catches <code class="docutils literal notranslate">Ts</code> 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. </section> <section id="a-new-except-alternative"> <h3><a class="toc-backref" href="#a-new-except-alternative" role="doc-backlink">A New <code class="docutils literal notranslate">except</code> Alternative</a></h3> We considered introducing a new keyword (such as <code class="docutils literal notranslate">catch</code>) which can be used to handle both naked exceptions and exception groups. Its semantics would be the same as those of <code class="docutils literal notranslate">except*</code> when catching an exception group, but it would not wrap a naked exception to create an exception group. This would have been part of a long term plan to replace <code class="docutils literal notranslate">except</code> by <code class="docutils literal notranslate">catch</code>, but we decided that deprecating <code class="docutils literal notranslate">except</code> in favour of an enhanced keyword would be too confusing for users at this time, so it is more appropriate to introduce the <code class="docutils literal notranslate">except*</code> syntax for exception groups while <code class="docutils literal notranslate">except</code> continues to be used for simple exceptions. </section> <section id="applying-an-except-clause-on-one-exception-at-a-time"> <h3><a class="toc-backref" href="#applying-an-except-clause-on-one-exception-at-a-time" role="doc-backlink">Applying an <code class="docutils literal notranslate">except*</code> Clause on One Exception at a Time</a></h3> We explained above that it is unsafe to execute an <code class="docutils literal notranslate">except</code> clause in existing code more than once, because the code may not be idempotent. We considered doing this in the new <code class="docutils literal notranslate">except*</code> clauses, where the backwards compatibility considerations do not exist. The idea is to always execute an <code class="docutils literal notranslate">except*</code> clause on a single exception, possibly executing the same clause multiple times when it matches multiple exceptions. We decided instead to execute each <code class="docutils literal notranslate">except*</code> clause at most once, giving it an exception group that contains all matching exceptions. The reason for this decision was the observation that when a program needs to know the particular context of an exception it is handling, the exception is handled before it is grouped and raised together with other exceptions. For example, <code class="docutils literal notranslate">KeyError</code> is an exception that typically relates to a certain operation. Any recovery code would be local to the place where the error occurred, and would use the traditional <code class="docutils literal notranslate">except</code>: <div class="highlight-default notranslate"><div class="highlight"><pre>try: dct[key] except KeyError: # handle the exception </pre></div> </div> It is unlikely that asyncio users would want to do something like this: <div class="highlight-default notranslate"><div class="highlight"><pre>try: async with asyncio.TaskGroup() as g: g.create_task(task1); g.create_task(task2) except* KeyError: # handling KeyError here is meaningless, there's # no context to do anything with it but to log it. </pre></div> </div> When a program handles a collection of exceptions that were aggregated into an exception group, it would not typically attempt to recover from any particular failed operation, but will rather use the types of the errors to determine how they should impact the program’s control flow or what logging or cleanup is required. This decision is likely to be the same whether the group contains a single or multiple instances of something like a <code class="docutils literal notranslate">KeyboardInterrupt</code> or <code class="docutils literal notranslate">asyncio.CancelledError</code>. Therefore, it is more convenient to handle all exceptions matching an <code class="docutils literal notranslate">except*</code> at once. If it does turn out to be necessary, the handler can inpect the exception group and process the individual exceptions in it. </section> <section id="not-matching-naked-exceptions-in-except"> <h3><a class="toc-backref" href="#not-matching-naked-exceptions-in-except" role="doc-backlink">Not Matching Naked Exceptions in <code class="docutils literal notranslate">except*</code></a></h3> We considered the option of making <code class="docutils literal notranslate">except* T</code> match only exception groups that contain <code class="docutils literal notranslate">Ts</code>, but not naked <code class="docutils literal notranslate">Ts</code>. To see why we thought this would not be a desirable feature, return to the distinction in the previous paragraph between operation errors and control flow exceptions. If we don’t know whether we should expect naked exceptions or exception groups from the body of a <code class="docutils literal notranslate">try</code> block, then we’re not in the position of handling operation errors. Rather, we are likely calling a fairly generic function and will be handling errors to make control flow decisions. We are likely to do the same thing whether we catch a naked exception of type <code class="docutils literal notranslate">T</code> or an exception group with one or more <code class="docutils literal notranslate">Ts</code>. Therefore, the burden of having to explicitly handle both is not likely to have semantic benefit. If it does turn out to be necessary to make the distinction, it is always possible to nest in the <code class="docutils literal notranslate">try-except*</code> clause an additional <code class="docutils literal notranslate">try-except</code> clause which intercepts and handles a naked exception before the <code class="docutils literal notranslate">except*</code> clause has a chance to wrap it in an exception group. In this case the overhead of specifying both is not additional burden - we really do need to write a separate code block to handle each case: <div class="highlight-default notranslate"><div class="highlight"><pre>try: try: ... except SomeError: # handle the naked exception except* SomeError: # handle the exception group </pre></div> </div> </section> <section id="allow-mixing-except-and-except-in-the-same-try"> <h3><a class="toc-backref" href="#allow-mixing-except-and-except-in-the-same-try" role="doc-backlink">Allow mixing <code class="docutils literal notranslate">except:</code> and <code class="docutils literal notranslate">except*:</code> in the same <code class="docutils literal notranslate">try</code></a></h3> This option was rejected because it adds complexity without adding useful semantics. Presumably the intention would be that an <code class="docutils literal notranslate">except T:</code> block handles only naked exceptions of type <code class="docutils literal notranslate">T</code>, while <code class="docutils literal notranslate">except* T:</code> handles <code class="docutils literal notranslate">T</code> in exception groups. We already discussed above why this is unlikely to be useful in practice, and if it is needed then the nested <code class="docutils literal notranslate">try-except</code> block can be used instead to achieve the same result. </section> <section id="try-instead-of-except"> <h3><a class="toc-backref" href="#try-instead-of-except" role="doc-backlink"><code class="docutils literal notranslate">try*</code> instead of <code class="docutils literal notranslate">except*</code></a></h3> Since either all or none of the clauses of a <code class="docutils literal notranslate">try</code> construct are <code class="docutils literal notranslate">except*</code>, we considered changing the syntax of the <code class="docutils literal notranslate">try</code> instead of all the <code class="docutils literal notranslate">except*</code> clauses. We rejected this because it would be less obvious. The fact that we are handling exception groups of <code class="docutils literal notranslate">T</code> rather than only naked <code class="docutils literal notranslate">Ts</code> should be specified in the same place where we state <code class="docutils literal notranslate">T</code>. </section> <section id="alternative-syntax-options"> <h3><a class="toc-backref" href="#alternative-syntax-options" role="doc-backlink">Alternative syntax options</a></h3> Alternatives to the <code class="docutils literal notranslate">except*</code> syntax were evaluated in a <a class="reference external" href="http://groups.google.com/g/dev-python/c/G3p9_jovyus">discussion on python-dev</a>, and it was suggested to use <code class="docutils literal notranslate">except group</code>. Upon careful evaluation this was rejected because the following would be ambiguous, as it is currently valid syntax where <code class="docutils literal notranslate">group</code> is interpreted as a callable. The same is true for any valid identifier. <div class="highlight-default notranslate"><div class="highlight"><pre>try: ... except group (T1, T2): ... </pre></div> </div> </section> </section> <section id="programming-without-except"> <h2><a class="toc-backref" href="#programming-without-except" role="doc-backlink">Programming Without ‘except *’</a></h2> Consider the following simple example of the <code class="docutils literal notranslate">except*</code> syntax (pretending Trio natively supported this proposal): <div class="highlight-default notranslate"><div class="highlight"><pre>try: async with trio.open_nursery() as nursery: # Make two concurrent calls to child() nursery.start_soon(child) nursery.start_soon(child) except* ValueError: pass </pre></div> </div> Here is how this code would look in Python 3.9: <div class="highlight-default notranslate"><div class="highlight"><pre>def handle_ValueError(exc): if isinstance(exc, ValueError): return None else: return exc # reraise exc with MultiError.catch(handle_ValueError): async with trio.open_nursery() as nursery: # Make two concurrent calls to child() nursery.start_soon(child) nursery.start_soon(child) </pre></div> </div> This example clearly demonstrates how unintuitive and cumbersome handling of multiple errors is in current Python. The exception handling logic has to be in a separate closure and is fairly low level, requiring the writer to have non-trivial understanding of both Python exceptions mechanics and the Trio APIs. Instead of using the <code class="docutils literal notranslate">try..except</code> block we have to use a <code class="docutils literal notranslate">with</code> block. We need to explicitly reraise exceptions we are not handling. Handling more exception types or implementing more complex exception handling logic will only further complicate the code to the point of it being unreadable. </section> <section id="see-also"> <h2><a class="toc-backref" href="#see-also" role="doc-backlink">See Also</a></h2> <ul class="simple"> <li>An analysis of how exception groups will likely be used in asyncio programs: <a class="footnote-reference brackets" href="#id28" id="id15">[10]</a>.</li> <li>The issue where the <code class="docutils literal notranslate">except*</code> concept was first formalized: <a class="footnote-reference brackets" href="#id30" id="id16">[12]</a>.</li> <li><code class="docutils literal notranslate">MultiError2</code> design document: <a class="footnote-reference brackets" href="#id21" id="id17">[3]</a>.</li> <li>Reporting Multiple Errors in the Hypothesis library: <a class="footnote-reference brackets" href="#id25" id="id18">[7]</a>.</li> </ul> </section> <section id="acknowledgements"> <h2><a class="toc-backref" href="#acknowledgements" role="doc-backlink">Acknowledgements</a></h2> We wish to thank Nathaniel J. Smith and the other Trio developers for their work on structured concurrency. We borrowed the idea of constructing an exception tree whose nodes are exceptions from MultiError, and the <code class="docutils literal notranslate">split()</code> API from the design document for MultiError V2. The discussions on python-dev and elsewhere helped us improve upon the first draft of the PEP in multiple ways, both the design and the exposition. For this we appreciate all those who contributed ideas and asked good questions: Ammar Askar, Matthew Barnett, Ran Benita, Emily Bowman, Brandt Bucher, Joao Bueno, Baptiste Carvello, Rob Cliffe, Alyssa Coghlan, Steven D’Aprano, Caleb Donovick, Steve Dower, Greg Ewing, Ethan Furman, Pablo Salgado, Jonathan Goble, Joe Gottman, Thomas Grainger, Larry Hastings, Zac Hatfield-Dodds, Chris Jerdonek, Jim Jewett, Sven Kunze, Łukasz Langa, Glenn Linderman, Paul Moore, Antoine Pitrou, Ivan Pozdeev, Patrick Reader, Terry Reedy, Sascha Schlemmer, Barry Scott, Mark Shannon, Damian Shaw, Cameron Simpson, Gregory Smith, Paul Sokolovsky, Calvin Spealman, Steve Stagg, Victor Stinner, Marco Sulla, Petr Viktorin and Barry Warsaw. </section> <section id="acceptance"> <h2><a class="toc-backref" href="#acceptance" role="doc-backlink">Acceptance</a></h2> <a class="pep reference internal" href="../pep-0654/" title="PEP 654 – Exception Groups and except*">PEP 654</a> was <a class="reference external" href="http://discuss.python.org/t/accepting-pep-654-exception-groups-and-except/10813">accepted by Thomas Wouters on Sep 24, 2021</a>. </section> <section id="references"> <h2><a class="toc-backref" href="#references" role="doc-backlink">References</a></h2> <aside class="footnote-list brackets"> <aside class="footnote brackets" id="id19" role="doc-footnote"> <dt class="label" id="id19">[<a href="#id1">1</a>]</dt> <dd><a class="reference external" href="https://docs.python.org/3/library/asyncio-task.html#asyncio.gather">https://docs.python.org/3/library/asyncio-task.html#asyncio.gather</a></aside> <aside class="footnote brackets" id="id20" role="doc-footnote"> <dt class="label" id="id20">[2] (<a href='#id2'>1</a>, <a href='#id11'>2</a>) </dt> <dd><a class="reference external" href="https://trio.readthedocs.io/en/stable/">https://trio.readthedocs.io/en/stable/</a></aside> <aside class="footnote brackets" id="id21" role="doc-footnote"> <dt class="label" id="id21">[3] (<a href='#id4'>1</a>, <a href='#id17'>2</a>) </dt> <dd><a class="reference external" href="https://github.com/python-trio/trio/issues/611">https://github.com/python-trio/trio/issues/611</a></aside> <aside class="footnote brackets" id="id22" role="doc-footnote"> <dt class="label" id="id22">[<a href="#id6">4</a>]</dt> <dd><a class="reference external" href="https://github.com/python/cpython/issues/74166">https://github.com/python/cpython/issues/74166</a></aside> <aside class="footnote brackets" id="id23" role="doc-footnote"> <dt class="label" id="id23">[<a href="#id7">5</a>]</dt> <dd><a class="reference external" href="https://docs.python.org/3/library/atexit.html#atexit.register">https://docs.python.org/3/library/atexit.html#atexit.register</a></aside> <aside class="footnote brackets" id="id24" role="doc-footnote"> <dt class="label" id="id24">[<a href="#id8">6</a>]</dt> <dd><a class="reference external" href="https://github.com/pytest-dev/pytest/issues/8217">https://github.com/pytest-dev/pytest/issues/8217</a></aside> <aside class="footnote brackets" id="id25" role="doc-footnote"> <dt class="label" id="id25">[7] (<a href='#id9'>1</a>, <a href='#id18'>2</a>) </dt> <dd><a class="reference external" href="https://hypothesis.readthedocs.io/en/latest/settings.html#hypothesis.settings.report_multiple_bugs">https://hypothesis.readthedocs.io/en/latest/settings.html#hypothesis.settings.report_multiple_bugs</a></aside> <aside class="footnote brackets" id="id26" role="doc-footnote"> <dt class="label" id="id26">[<a href="#id10">8</a>]</dt> <dd><a class="reference external" href="https://github.com/python/cpython/issues/85034">https://github.com/python/cpython/issues/85034</a></aside> <aside class="footnote brackets" id="id27" role="doc-footnote"> <dt class="label" id="id27">[9] (<a href='#id3'>1</a>, <a href='#id12'>2</a>) </dt> <dd><a class="reference external" href="https://trio.readthedocs.io/en/stable/reference-core.html#trio.MultiError">https://trio.readthedocs.io/en/stable/reference-core.html#trio.MultiError</a></aside> <aside class="footnote brackets" id="id28" role="doc-footnote"> <dt class="label" id="id28">[10] (<a href='#id13'>1</a>, <a href='#id15'>2</a>) </dt> <dd><a class="reference external" href="https://github.com/python/exceptiongroups/issues/3#issuecomment-716203284">https://github.com/python/exceptiongroups/issues/3#issuecomment-716203284</a></aside> <aside class="footnote brackets" id="id29" role="doc-footnote"> <dt class="label" id="id29">[<a href="#id14">11</a>]</dt> <dd><a class="reference external" href="https://github.com/iritkatriel/cpython/tree/exceptionGroup-stage5">https://github.com/iritkatriel/cpython/tree/exceptionGroup-stage5</a></aside> <aside class="footnote brackets" id="id30" role="doc-footnote"> <dt class="label" id="id30">[<a href="#id16">12</a>]</dt> <dd><a class="reference external" href="https://github.com/python/exceptiongroups/issues/4">https://github.com/python/exceptiongroups/issues/4</a></aside> <aside class="footnote brackets" id="id31" role="doc-footnote"> <dt class="label" id="id31">[<a href="#id5">13</a>]</dt> <dd><a class="reference external" href="https://trio.readthedocs.io/en/stable/reference-core.html#nurseries-and-spawning">https://trio.readthedocs.io/en/stable/reference-core.html#nurseries-and-spawning</a></aside> </aside> </section> <section id="copyright"> <h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2> This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive. </section> </section> <hr class="docutils" /> Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-0654.rst">https://github.com/python/peps/blob/main/peps/pep-0654.rst</a> Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-0654.rst">2025-02-01 08:55:40 GMT</a> </article> <nav id="pep-sidebar"> <h2>Contents</h2> <ul> <li><a class="reference internal" href="#abstract">Abstract</a></li> <li><a class="reference internal" href="#motivation">Motivation</a></li> <li><a class="reference internal" href="#rationale">Rationale</a></li> <li><a class="reference internal" href="#specification">Specification</a><ul> <li><a class="reference internal" href="#exceptiongroup-and-baseexceptiongroup">ExceptionGroup and BaseExceptionGroup</a><ul> <li><a class="reference internal" href="#subclassing-exception-groups">Subclassing Exception Groups</a></li> <li><a class="reference internal" href="#the-traceback-of-an-exception-group">The Traceback of an Exception Group</a></li> <li><a class="reference internal" href="#handling-exception-groups">Handling Exception Groups</a></li> </ul> </li> <li><a class="reference internal" href="#except">except*</a><ul> <li><a class="reference internal" href="#recursive-matching">Recursive Matching</a></li> <li><a class="reference internal" href="#unmatched-exceptions">Unmatched Exceptions</a></li> <li><a class="reference internal" href="#naked-exceptions">Naked Exceptions</a></li> <li><a class="reference internal" href="#raising-exceptions-in-an-except-block">Raising exceptions in an <code class="docutils literal notranslate">except*</code> block</a></li> <li><a class="reference internal" href="#chaining">Chaining</a></li> <li><a class="reference internal" href="#raising-new-exceptions">Raising New Exceptions</a></li> <li><a class="reference internal" href="#caught-exception-objects">Caught Exception Objects</a></li> <li><a class="reference internal" href="#forbidden-combinations">Forbidden Combinations</a></li> </ul> </li> </ul> </li> <li><a class="reference internal" href="#backwards-compatibility">Backwards Compatibility</a></li> <li><a class="reference internal" href="#how-to-teach-this">How to Teach This</a></li> <li><a class="reference internal" href="#reference-implementation">Reference Implementation</a></li> <li><a class="reference internal" href="#rejected-ideas">Rejected Ideas</a><ul> <li><a class="reference internal" href="#make-exception-groups-iterable">Make Exception Groups Iterable</a></li> <li><a class="reference internal" href="#make-exceptiongroup-extend-baseexception">Make <code class="docutils literal notranslate">ExceptionGroup</code> Extend <code class="docutils literal notranslate">BaseException</code></a></li> <li><a class="reference internal" href="#make-it-impossible-to-wrap-baseexceptions-in-an-exception-group">Make it Impossible to Wrap <code class="docutils literal notranslate">BaseExceptions</code> in an Exception Group</a></li> <li><a class="reference internal" href="#traceback-representation">Traceback Representation</a></li> <li><a class="reference internal" href="#extend-except-to-handle-exception-groups">Extend <code class="docutils literal notranslate">except</code> to Handle Exception Groups</a></li> <li><a class="reference internal" href="#a-new-except-alternative">A New <code class="docutils literal notranslate">except</code> Alternative</a></li> <li><a class="reference internal" href="#applying-an-except-clause-on-one-exception-at-a-time">Applying an <code class="docutils literal notranslate">except*</code> Clause on One Exception at a Time</a></li> <li><a class="reference internal" href="#not-matching-naked-exceptions-in-except">Not Matching Naked Exceptions in <code class="docutils literal notranslate">except*</code></a></li> <li><a class="reference internal" href="#allow-mixing-except-and-except-in-the-same-try">Allow mixing <code class="docutils literal notranslate">except:</code> and <code class="docutils literal notranslate">except*:</code> in the same <code class="docutils literal notranslate">try</code></a></li> <li><a class="reference internal" href="#try-instead-of-except"><code class="docutils literal notranslate">try*</code> instead of <code class="docutils literal notranslate">except*</code></a></li> <li><a class="reference internal" href="#alternative-syntax-options">Alternative syntax options</a></li> </ul> </li> <li><a class="reference internal" href="#programming-without-except">Programming Without ‘except *’</a></li> <li><a class="reference internal" href="#see-also">See Also</a></li> <li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li> <li><a class="reference internal" href="#acceptance">Acceptance</a></li> <li><a class="reference internal" href="#references">References</a></li> <li><a class="reference internal" href="#copyright">Copyright</a></li> </ul> <a id="source" href="https://github.com/python/peps/blob/main/peps/pep-0654.rst">Page Source (GitHub)</a> </nav> </section> <script src="../_static/colour_scheme.js"></script> <script src="../_static/wrap_tables.js"></script> <script src="../_static/sticky_banner.js"></script> </body> </html>