PEP-654: fix level of subsection headings (#1832)
This commit is contained in:
parent
3daf8f2199
commit
e7193a3e63
16
pep-0654.rst
16
pep-0654.rst
|
@ -383,7 +383,7 @@ The order of ``except*`` clauses is significant just like with the regular
|
|||
ExceptionGroup('problem', [BlockingIOError()])
|
||||
|
||||
Recursive Matching
|
||||
------------------
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The matching of ``except*`` clauses against an ``ExceptionGroup`` is performed
|
||||
recursively, using the ``ExceptionGroup.split()`` method:
|
||||
|
@ -411,7 +411,7 @@ recursively, using the ``ExceptionGroup.split()`` method:
|
|||
>>>
|
||||
|
||||
Unmatched Exceptions
|
||||
--------------------
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If not all exceptions in an ``ExceptionGroup`` were matched by the ``except*``
|
||||
clauses, the remaining part of the ``ExceptionGroup`` is propagated on:
|
||||
|
@ -440,7 +440,7 @@ clauses, the remaining part of the ``ExceptionGroup`` is propagated on:
|
|||
|
||||
|
||||
Naked Exceptions
|
||||
----------------
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
If the exception raised inside the ``try`` body is not of type ``ExceptionGroup``,
|
||||
we call it a ``naked`` exception. If its type matches one of the ``except*``
|
||||
|
@ -473,7 +473,7 @@ naked form:
|
|||
>>>
|
||||
|
||||
Raising exceptions in an ``except*`` block
|
||||
------------------------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In a traditional ``except`` block, there are two ways to raise exceptions:
|
||||
``raise e`` to explicitly raise an exception object ``e``, or naked ``raise`` to
|
||||
|
@ -617,7 +617,7 @@ merged with the unhandled ``TypeErrors``.
|
|||
|
||||
|
||||
Chaining
|
||||
--------
|
||||
~~~~~~~~
|
||||
|
||||
Explicitly raised ``ExceptionGroups`` are chained as with any exceptions. The
|
||||
following example shows how part of ``ExceptionGroup`` "one" became the
|
||||
|
@ -663,7 +663,7 @@ it into the new ``ExceptionGroup``.
|
|||
|
||||
|
||||
Raising New Exceptions
|
||||
----------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In the previous examples the explicit raises were of the exceptions that
|
||||
were caught, so for completion we show a new exception being raise, with
|
||||
|
@ -807,7 +807,7 @@ while letting all other exceptions propagate.
|
|||
|
||||
|
||||
Caught Exception Objects
|
||||
------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is important to point out that the ``ExceptionGroup`` bound to ``e`` is an
|
||||
ephemeral object. Raising it via ``raise`` or ``raise e`` will not cause changes
|
||||
|
@ -829,7 +829,7 @@ likely be lost:
|
|||
|
||||
|
||||
Forbidden Combinations
|
||||
----------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is not possible to use both traditional ``except`` blocks and the new
|
||||
``except*`` clauses in the same ``try`` statement. The following is a
|
||||
|
|
Loading…
Reference in New Issue