You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/source/reference-core.rst
+9-3Lines changed: 9 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -768,9 +768,14 @@ inside the handler function(s) with the ``nonlocal`` keyword::
768
768
async with trio.open_nursery() as nursery:
769
769
nursery.start_soon(broken1)
770
770
771
+
.. _strict_exception_groups:
772
+
771
773
"Strict" versus "loose" ExceptionGroup semantics
772
774
++++++++++++++++++++++++++++++++++++++++++++++++
773
775
776
+
..
777
+
TODO: rewrite this (and possible other) sections from the new strict-by-default perspective, under the heading "Deprecated: non-strict ExceptionGroups" - to explain that it only exists for backwards-compatibility, will be removed in future, and that we recommend against it for all new code.
778
+
774
779
Ideally, in some abstract sense we'd want everything that *can* raise an
775
780
`ExceptionGroup` to *always* raise an `ExceptionGroup` (rather than, say, a single
776
781
`ValueError`). Otherwise, it would be easy to accidentally write something like ``except
@@ -796,9 +801,10 @@ to set the default behavior for any nursery in your program that doesn't overrid
796
801
wrapping, so you'll get maximum compatibility with code that was written to
797
802
support older versions of Trio.
798
803
799
-
To maintain backwards compatibility, the default is ``strict_exception_groups=False``.
800
-
The default will eventually change to ``True`` in a future version of Trio, once
801
-
Python 3.11 and later versions are in wide use.
804
+
The default is set to ``strict_exception_groups=True``, in line with the default behaviour
805
+
of ``TaskGroup`` in asyncio and anyio. We've also found that non-strict mode makes it
806
+
too easy to neglect the possibility of several exceptions being raised concurrently,
807
+
causing nasty latent bugs when errors occur under load.
The :ref:`strict_exception_groups <strict_exception_groups>` parameter now defaults to `True` in `trio.run` and `trio.lowlevel.start_guest_run`. `trio.open_nursery` still defaults to the same value as was specified in `trio.run`/`trio.lowlevel.start_guest_run`, but if you didn't specify it there then all subsequent calls to `trio.open_nursery` will change.
2
+
This is unfortunately very tricky to change with a deprecation period, as raising a `DeprecationWarning` whenever :ref:`strict_exception_groups <strict_exception_groups>` is not specified would raise a lot of unnecessary warnings.
3
+
4
+
Notable side effects of changing code to run with ``strict_exception_groups==True``
5
+
6
+
* If an iterator raises `StopAsyncIteration` or `StopIteration` inside a nursery, then python will not recognize wrapped instances of those for stopping iteration.
7
+
* `trio.run_process` is now documented that it can raise an `ExceptionGroup`. It previously could do this in very rare circumstances, but with :ref:`strict_exception_groups <strict_exception_groups>` set to `True` it will now do so whenever exceptions occur in ``deliver_cancel`` or with problems communicating with the subprocess.
8
+
9
+
* Errors in opening the process is now done outside the internal nursery, so if code previously ran with ``strict_exception_groups=True`` there are cases now where an `ExceptionGroup` is *no longer* added.
10
+
* `trio.TrioInternalError` ``.__cause__`` might be wrapped in one or more `ExceptionGroups <ExceptionGroup>`
0 commit comments