ExceptionGroup und BaseExceptionGroup

Wir schlagen vor, zwei neue eingebaute Exception-Typen hinzuzufügen: BaseExceptionGroup(BaseException) und ExceptionGroup(BaseExceptionGroup, Exception). Sie sind zu Exception.__cause__ und Exception.__context__ zuweisbar und können wie jede Exception mit raise ExceptionGroup(...) und try: ... except ExceptionGroup: ... oder raise BaseExceptionGroup(...) und try: ... except BaseExceptionGroup: ... ausgelöst und behandelt werden.

Beide haben einen Konstruktor, der zwei positionsgebundene Argumente entgegennimmt: eine Nachrichtenzeichenkette und eine Sequenz der verschachtelten Exceptions, die in den Feldern message und exceptions verfügbar sind. Beispiel: ExceptionGroup('issues', [ValueError('bad value'), TypeError('bad type')]). Der Unterschied zwischen beiden besteht darin, dass ExceptionGroup nur Exception-Unterklassen verpacken kann, während BaseExceptionGroup jede BaseException-Unterklasse verpacken kann. Der Konstruktor von BaseExceptionGroup prüft die verschachtelten Exceptions und gibt eine ExceptionGroup zurück, wenn alle Exceptions Exception-Unterklassen sind, ansonsten eine BaseExceptionGroup. Der Konstruktor von ExceptionGroup löst eine TypeError aus, wenn eine der verschachtelten Exceptions keine Exception-Instanz ist. Im Rest des Dokuments meinen wir mit Exception Group entweder eine ExceptionGroup oder eine BaseExceptionGroup. Wenn die Unterscheidung notwendig ist, verwenden wir den Klassennamen. Zur Vereinfachung verwenden wir ExceptionGroup in Codebeispielen, die für beide relevant sind.

Da eine Exception Group verschachtelt sein kann, repräsentiert sie einen Baum von Exceptions, wobei die Blätter normale Exceptions sind und jeder innere Knoten eine Zeit darstellt, zu der das Programm einige unabhängige Exceptions zu einer neuen Gruppe zusammengefasst und gemeinsam ausgelöst hat.

Die Methode BaseExceptionGroup.subgroup(condition) bietet uns eine Möglichkeit, eine Exception Group zu erhalten, die dieselben Metadaten (Nachricht, Ursache, Kontext, Traceback) wie die ursprüngliche Gruppe hat und dieselbe verschachtelte Struktur von Gruppen, aber nur die Exceptions enthält, für die die Bedingung wahr ist.

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

Die Übereinstimmungsbedingung wird auch auf innere Knoten (die Exception Groups) angewendet, und eine Übereinstimmung bewirkt, dass der gesamte Teilbaum, der an diesem Knoten verwurzelt ist, in das Ergebnis aufgenommen wird.

Leere verschachtelte Gruppen werden aus dem Ergebnis weggelassen, wie im Beispiel von ExceptionGroup("three") oben. Wenn keine der Exceptions mit der Bedingung übereinstimmt, gibt subgroup None anstelle einer leeren Gruppe zurück. Die ursprüngliche eg wird durch subgroup nicht verändert, aber der zurückgegebene Wert ist nicht unbedingt eine vollständige neue Kopie. Blatt-Exceptions werden nicht kopiert, ebenso wenig Exception Groups, die vollständig im Ergebnis enthalten sind. Wenn eine Gruppe partitioniert werden muss, weil die Bedingung für einige, aber nicht alle darin enthaltenen Exceptions gilt, wird eine neue Instanz von ExceptionGroup oder BaseExceptionGroup erstellt, während die Felder __cause__, __context__ und __traceback__ per Referenz kopiert werden, sodass sie mit der ursprünglichen eg geteilt werden.

Wenn sowohl die Untergruppe als auch ihr Komplement benötigt werden, kann die Methode BaseExceptionGroup.split(condition) verwendet werden.

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

Wenn eine Teilung trivial ist (eine Seite ist leer), wird für die andere Seite None zurückgegeben.

>>> other_errors.split(lambda e: isinstance(e, SyntaxError))
(None, ExceptionGroup('one', [
  ExceptionGroup('two', [
    ValueError(3)
  ]),
  ExceptionGroup('three', [
    OSError(4)])]))

Da die Teilung nach Exception-Typ ein sehr häufiger Anwendungsfall ist, können subgroup und split einen Exception-Typ oder ein Tupel von Exception-Typen entgegennehmen und diese als Kurzform für die Übereinstimmung dieses Typs behandeln: eg.split(T) teilt eg in die Untergruppe der Blatt-Exceptions, die mit dem Typ T übereinstimmen, und die Untergruppe derer, die dies nicht tun (unter Verwendung derselben Prüfung wie except für eine Übereinstimmung).

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)

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

>>> 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)])
>>>

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

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

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()

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

except*

Wir schlagen vor, eine neue Variante der try..except-Syntax einzuführen, um die Arbeit mit Exception Groups zu vereinfachen. Das Zeichen * zeigt an, dass mehrere Exceptions von jeder except*-Klausel behandelt werden können.

try:
    ...
except* SpamError:
    ...
except* FooError as e:
    ...
except* (BarError, BazError) as e:
    ...

In einer traditionellen try-except-Anweisung gibt es nur eine Exception zu behandeln, daher wird der Körper von höchstens einer except-Klausel ausgeführt; die erste, die mit der Exception übereinstimmt. Mit der neuen Syntax kann eine except*-Klausel mit einer Untergruppe der ausgelösten Exception-Group übereinstimmen, während der verbleibende Teil von nachfolgenden except*-Klauseln übereingestimmt wird. Mit anderen Worten, eine einzelne Exception Group kann dazu führen, dass mehrere except*-Klauseln ausgeführt werden, aber jede solche Klausel wird höchstens einmal ausgeführt (für alle übereinstimmenden Exceptions aus der Gruppe) und jede Exception wird entweder von genau einer Klausel behandelt (der ersten, die ihrem Typ entspricht) oder am Ende erneut ausgelöst. Die Art und Weise, wie jede Exception von einem try-except*-Block behandelt wird, ist unabhängig von anderen Exceptions in der Gruppe.

Angenommen beispielsweise, der Körper des obigen try-Blocks löst eg = ExceptionGroup('msg', [FooError(1), FooError(2), BazError()]) aus. Die except*-Klauseln werden in Reihenfolge ausgewertet, indem split auf die unhandled Exception Group angewendet wird, die anfangs gleich eg ist und dann schrumpft, während Exceptions übereinstimmen und daraus extrahiert werden. In der ersten except*-Klausel gibt unhandled.split(SpamError) (None, unhandled) zurück, sodass der Körper dieses Blocks nicht ausgeführt wird und unhandled unverändert bleibt. Für den zweiten Block gibt unhandled.split(FooError) eine nicht-triviale Teilung (match, rest) zurück, mit match = ExceptionGroup('msg', [FooError(1), FooError(2)]) und rest = ExceptionGroup('msg', [BazError()]). Der Körper dieses except*-Blocks wird ausgeführt, wobei der Wert von e und sys.exc_info() auf match gesetzt wird. Dann wird unhandled auf rest gesetzt. Schließlich stimmt der dritte Block mit der verbleibenden Exception überein, sodass er mit e und sys.exc_info() gleich ExceptionGroup('msg', [BazError()]) ausgeführt wird.

Exceptions werden mithilfe einer Unterklassenprüfung abgeglichen. Zum Beispiel:

try:
    low_level_os_operation()
except* OSError as eg:
    for e in eg.exceptions:
        print(type(e).__name__)

könnte folgendes ausgeben:

BlockingIOError
ConnectionRefusedError
OSError
InterruptedError
BlockingIOError

Die Reihenfolge der except*-Klauseln ist wichtig, genau wie bei der regulären try..except-Anweisung.

>>> 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()])

>>> 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')])])
>>>

>>> 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')])
>>>

>>> try:
...     raise BlockingIOError
... except* OSError as e:
...     print(repr(e))
...
ExceptionGroup('', [BlockingIOError()])

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

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  |

>>> 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)])])
>>>

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

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

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

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

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

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

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

try:
    ...
except ValueError:
    pass
except* CancelledError:  # <- SyntaxError:
    pass                 #    combining ``except`` and ``except*``
                         #    is prohibited

try:
    ...
except ExceptionGroup:  # <- This works
    pass

try:
    ...
except* ExceptionGroup:  # <- Runtime error
    pass

try:
    ...
except* (TypeError, ExceptionGroup):  # <- Runtime error
    pass

try:
    ...
except*:   # <- SyntaxError
    pass

Exception Groups iterierbar machen

Wir haben erwogen, Ausnahme-Gruppen iterierbar zu machen, so dass list(eg) eine abgeflachte Liste der Blatt-Ausnahmen erzeugt, die in der Gruppe enthalten sind. Wir entschieden, dass dies keine solide API wäre, da die Metadaten (Ursache, Kontext und Traceback) der einzelnen Ausnahmen in einer Gruppe unvollständig sind und dies Probleme verursachen könnte.

Darüber hinaus, wie wir im Abschnitt Handling Exception Groups erklärt haben, halten wir es für unwahrscheinlich, dass die Iteration über Blatt-Ausnahmen viele Anwendungsfälle haben wird. Wir haben dort jedoch den Code für einen Traversierungsalgorithmus bereitgestellt, der die Metadaten jeder Blatt-Ausnahme korrekt konstruiert. Wenn sich dies in der Praxis als nützlich erweist, können wir diese Funktionalität zukünftig zur Standardbibliothek hinzufügen oder Ausnahme-Gruppen sogar iterierbar machen.

ExceptionGroup von BaseException erben lassen

Wir erwogen, ExceptionGroup nur von BaseException und nicht von Exception erben zu lassen. Die Begründung dafür war, dass wir erwarten, dass Ausnahme-Gruppen auf bewusste Weise verwendet werden, wo sie benötigt werden, und nur von APIs ausgelöst werden, die speziell dafür konzipiert und dokumentiert sind. In diesem Kontext ist eine ExceptionGroup, die aus einer API entkommt, die sie nicht auslösen soll, ein Fehler, und wir wollten ihr den Status „fatal error“ geben, damit except Exception sie nicht versehentlich verschluckt. Dies wäre mit der Art und Weise vereinbar, wie except T: keine Ausnahme-Gruppen abfängt, die T für alle anderen Typen enthalten, und würde helfen, ExceptionGroups auf die Teile des Programms zu beschränken, in denen sie erscheinen sollen. Es war jedoch aus der öffentlichen Diskussion klar, dass T=Exception ein Sonderfall ist, und es gibt Entwickler, die der Meinung sind, dass except Exception: „fast alles“ abfangen sollte, einschließlich Ausnahme-Gruppen. Deshalb haben wir beschlossen, ExceptionGroup zu einer Unterklasse von Exception zu machen.

Verhindern, dass BaseExceptions in einer Exception Group verpackt werden

Eine Folge der Entscheidung, ExceptionGroup von Exception erben zu lassen, ist, dass ExceptionGroup keine BaseExceptions wie KeyboardInterrupt umschließen sollte, da diese derzeit nicht von except Exception: abgefangen werden. Wir haben die Option in Betracht gezogen, es einfach unmöglich zu machen, BaseExceptions zu umschließen, haben uns aber schließlich entschieden, es durch den Typ BaseExceptionGroup zu ermöglichen, der von BaseException und nicht von Exception erbt. Dies zu ermöglichen, verleiht der Sprache Flexibilität und überlässt es dem Programmierer abzuwägen, welchen Vorteil das Umschließen von BaseExceptions gegenüber ihrer naked-Form und dem Verwerfen aller anderen Ausnahmen hat.

Traceback-Darstellung

Wir haben Optionen zur Anpassung der Traceback-Datenstruktur zur Darstellung von Bäumen in Betracht gezogen, aber es wurde offensichtlich, dass ein Traceback-Baum nicht sinnvoll ist, sobald er von den Ausnahmen getrennt ist, auf die er sich bezieht. Während ein Traceback mit einfachem Pfad mit einem with_traceback()-Aufruf an jede Ausnahme angehängt werden kann, ist es schwer vorstellbar, dass es sinnvoll wäre, einem Ausnahme-Gruppen-Traceback-Baum zuzuweisen. Darüber hinaus enthält eine nützliche Anzeige des Tracebacks Informationen über die verschachtelten Ausnahmen. Aus diesen Gründen haben wir beschlossen, den Traceback-Mechanismus so zu belassen, wie er ist, und den Traceback-Anzeigecode zu ändern.

except erweitern, um Exception Groups zu behandeln

Wir haben erwogen, die Semantik von except zu erweitern, um Ausnahme-Gruppen zu behandeln, anstatt except* einzuführen. Es gab zwei Abwärtskompatibilitätsprobleme damit. Das erste ist der Typ der abgefangenen Ausnahme. Betrachten Sie dieses Beispiel:

try:
    . . .
except OSError as err:
    if err.errno != ENOENT:
        raise

Wenn der Wert, der err zugewiesen wird, eine Ausnahme-Gruppe ist, die alle ausgelösten OSErrors enthält, dann funktioniert der Attributzugriff err.errno nicht mehr. Wir müssten also den Körper der except-Klausel mehrmals ausführen, einmal für jede Ausnahme in der Gruppe. Dies ist jedoch ebenfalls eine potenziell breakende Änderung, da wir derzeit except-Klauseln in der Kenntnis schreiben, dass sie nur einmal ausgeführt werden. Wenn dort eine nicht-idempotente Operation stattfindet, wie z. B. die Freigabe einer Ressource, könnte die Wiederholung schädlich sein.

Die Idee, except über die Blatt-Ausnahmen einer Ausnahme-Gruppe iterieren zu lassen, steht im Mittelpunkt eines alternativen Vorschlags zu diesem PEP von Nathaniel J. Smith, und die Diskussion über diesen Vorschlag erläutert weiter die Fallstricke der Änderung der except-Semantik in einer etablierten Sprache wie Python, sowie die Abweichung von den Semantiken, die parallele Konstrukte in anderen Sprachen haben.

Eine weitere Option, die in der öffentlichen Diskussion aufkam, war die Einführung von except*, aber auch die Behandlung von ExceptionGroups als Sonderfall durch except. except würde dann so etwas wie das Extrahieren einer Ausnahme des passenden Typs aus der Gruppe tun, um sie zu behandeln (während alle anderen Ausnahmen in der Gruppe verworfen werden). Die Motivation hinter diesen Vorschlägen war, die Einführung von Ausnahme-Gruppen sicherer zu machen, da except T Ts abfängt, die in Ausnahme-Gruppen verpackt sind. Wir haben entschieden, dass ein solcher Ansatz die Komplexität der Sprachsemantik erheblich erhöht, ohne sie leistungsfähiger zu machen. Selbst wenn er die Einführung von Ausnahme-Gruppen etwas erleichtern würde (was keineswegs offensichtlich ist), sind dies nicht die Semantiken, die wir uns langfristig wünschen.

Eine neue except-Alternative

Wir erwogen die Einführung eines neuen Schlüsselworts (wie z. B. catch), das verwendet werden kann, um sowohl naked-Ausnahmen als auch Ausnahme-Gruppen zu behandeln. Seine Semantik wäre dieselbe wie die von except* beim Abfangen einer Ausnahme-Gruppe, aber es würde eine naked-Ausnahme nicht zu einer Ausnahme-Gruppe umschließen. Dies wäre Teil eines langfristigen Plans, except durch catch zu ersetzen, aber wir entschieden, dass die Deprekation von except zugunsten eines erweiterten Schlüsselworts für Benutzer zu verwirrend wäre, sodass es angemessener ist, die except*-Syntax für Ausnahme-Gruppen einzuführen, während except weiterhin für einfache Ausnahmen verwendet wird.

Eine except*-Klausel auf eine Exception gleichzeitig anwenden

Wir haben oben erklärt, dass es unsicher ist, eine except-Klausel im bestehenden Code mehr als einmal auszuführen, da der Code möglicherweise nicht idempotent ist. Wir haben erwogen, dies in den neuen except*-Klauseln zu tun, wo die Abwärtskompatibilitätsüberlegungen nicht bestehen. Die Idee ist, eine except*-Klausel immer für eine einzelne Ausnahme auszuführen, wobei möglicherweise dieselbe Klausel mehrmals ausgeführt wird, wenn sie auf mehrere Ausnahmen zutrifft. Wir haben uns stattdessen entschieden, jede except*-Klausel höchstens einmal auszuführen und ihr eine Ausnahme-Gruppe zu geben, die alle passenden Ausnahmen enthält. Der Grund für diese Entscheidung war die Beobachtung, dass, wenn ein Programm den spezifischen Kontext einer Ausnahme kennen muss, die es behandelt, die Ausnahme behandelt wird, bevor sie gruppiert und zusammen mit anderen Ausnahmen ausgelöst wird.

Zum Beispiel ist KeyError eine Ausnahme, die typischerweise mit einer bestimmten Operation zusammenhängt. Jeder Wiederherstellungscode wäre lokal zu dem Ort, an dem der Fehler aufgetreten ist, und würde die traditionelle except-Klausel verwenden.

try:
    dct[key]
except KeyError:
    # handle the exception

Es ist unwahrscheinlich, dass asyncio-Benutzer so etwas tun möchten.

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.

Wenn ein Programm eine Sammlung von Ausnahmen behandelt, die zu einer Ausnahme-Gruppe aggregiert wurden, wird es normalerweise nicht versuchen, von einer bestimmten fehlgeschlagenen Operation wiederherzustellen, sondern wird die Typen der Fehler verwenden, um zu bestimmen, wie sie den Kontrollfluss des Programms beeinflussen sollten oder welche Protokollierung oder Bereinigung erforderlich ist. Diese Entscheidung wird wahrscheinlich dieselbe sein, unabhängig davon, ob die Gruppe eine oder mehrere Instanzen von etwas wie einem KeyboardInterrupt oder asyncio.CancelledError enthält. Daher ist es bequemer, alle Ausnahmen, die mit einer except* übereinstimmen, auf einmal zu behandeln. Wenn dies notwendig wird, kann der Handler die Ausnahme-Gruppe untersuchen und die einzelnen Ausnahmen darin verarbeiten.

Keine Übereinstimmung mit nackten Exceptions in except*

Wir haben die Option in Betracht gezogen, except* T so zu gestalten, dass es nur Ausnahme-Gruppen abgleicht, die Ts enthalten, aber nicht naked Ts. Um zu sehen, warum wir dachten, dass dies keine wünschenswerte Funktion wäre, kehren wir zur Unterscheidung im vorherigen Absatz zwischen Betriebsfehlern und Kontrollfluss-Ausnahmen zurück. Wenn wir nicht wissen, ob wir naked-Ausnahmen oder Ausnahme-Gruppen aus dem Körper eines try-Blocks erwarten sollen, dann sind wir nicht in der Lage, Betriebsfehler zu behandeln. Vielmehr rufen wir wahrscheinlich eine ziemlich generische Funktion auf und werden Fehler behandeln, um Entscheidungen über den Kontrollfluss zu treffen. Wir werden wahrscheinlich dasselbe tun, egal ob wir eine naked-Ausnahme vom Typ T oder eine Ausnahme-Gruppe mit einem oder mehreren Ts abfangen. Daher ist die Last, beides explizit behandeln zu müssen, wahrscheinlich nicht von semantischem Nutzen.

Wenn es sich als notwendig erweist, die Unterscheidung zu treffen, ist es immer möglich, in die try-except*-Klausel eine zusätzliche try-except-Klausel zu verschachteln, die eine naked-Ausnahme abfängt und behandelt, bevor die except*-Klausel sie in eine Ausnahme-Gruppe einpacken kann. In diesem Fall ist der Overhead der Spezifizierung beider keine zusätzliche Belastung – wir müssen wirklich einen separaten Codeblock schreiben, um jeden Fall zu behandeln.

try:
    try:
        ...
    except SomeError:
        # handle the naked exception
except* SomeError:
    # handle the exception group

Mischen von except: und except*: im selben try erlauben

Diese Option wurde abgelehnt, da sie Komplexität hinzufügt, ohne nützliche Semantik. Vermutlich wäre die Absicht, dass ein except T:-Block nur naked-Ausnahmen vom Typ T behandelt, während except* T: T in Ausnahme-Gruppen behandelt. Wir haben bereits oben diskutiert, warum dies in der Praxis wahrscheinlich nicht nützlich ist, und wenn es benötigt wird, kann der verschachtelte try-except-Block stattdessen verwendet werden, um dasselbe Ergebnis zu erzielen.

try* statt except*

Da entweder alle oder keine der Klauseln eines try-Konstrukts except* sind, haben wir erwogen, die Syntax von try anstelle aller except*-Klauseln zu ändern. Wir haben dies abgelehnt, da es weniger offensichtlich wäre. Die Tatsache, dass wir Ausnahme-Gruppen von T anstelle von nur naked Ts behandeln, sollte an derselben Stelle angegeben werden, an der wir T angeben.

Alternative Syntaxoptionen

Alternativen zur except*-Syntax wurden in einer Diskussion auf python-dev evaluiert, und es wurde vorgeschlagen, except group zu verwenden. Nach sorgfältiger Auswertung wurde dies abgelehnt, da das Folgende mehrdeutig wäre, da es derzeit gültige Syntax ist, bei der group als aufrufbar interpretiert wird. Dasselbe gilt für jeden gültigen Bezeichner.

try:
   ...
except group (T1, T2):
   ...