So a statement that the current handling is "cumbersome" and "unintuitive" is unconvincing.
If this results in lots of boilerplate code with isinstance(),
filter() can be changed to e.g. accept a dict of exception types
and handlers. Actually, I wonder why you didn't do that already if
handling specific exception types and reraising the rest is the
standard procedure!
Then the code would be reduced to:
try:
<smth>
except (MultiError, ValueError) as e:
MultiError.filter({ValueError: lambda
_: None},
e)
If some code doesn't know about MultiError's, it should handle
one like any other unknown exception that it cannot do anything
intelligent about.
If it wishes to handle them, you need to split MultiError into a
separate library that anyone could use without having to pull the
entire `trio`.
Hi all,
We would like to request feedback on PEP 654 -- Exception Groups and except*.
It proposes language extensions that allow programs to raise and handle multiple unrelatedexceptions simultaneously, motivated by the needs of asyncio and other concurrency libraries,but with other use cases as well.
* A new standard exception type, ExceptionGroup, to represent multiple exceptions withshared traceback.* Updates to the traceback printing code to display (possibly nested) ExceptionGroups.
* A new syntax except* for handling ExceptionGroups.
A reference implementation (unreviewed) can be found at:
Thank you for your help
Kind regardsIrit, Yury & Guido
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/L5Q27DVKOKZCDNCAWRIQVOZ5DZCZHLRM/ Code of Conduct: http://python.org/psf/codeofconduct/
-- Regards, Ivan