I just have two questions regarding "except Exception" or "except BaseException" as it is used e.g. by concurrent.futures.process (def _process_worker) from the stdlib.
Almost similarly, I maintain a library using this pattern to
wrap/unwrap exceptions from remote Python processes to create
nicely formatted tracebacks (also recursively of course if needed)
at the calling python process.
Usually these exceptions are wrapped, transferred to the parent process, there is the current call stack added, then reraised as a different exception, and so on and so forth if a chain of parents exist. The outermost parent process takes care of printing the tb.
My two questions regarding PEP 654:
1) What is the right "except pattern" when ExceptionGroup is
introduced for the use cases described above (remote or concurrent
2) What is the recommended approach of printing the traceback
potentially incorporating multiple tracebacks - I couldn't find it
in the PEP and tracebacks are a really neat tool for error
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 -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/L5Q27DVKOKZCDNCAWRIQVOZ5DZCZHLRM/ Code of Conduct: http://python.org/psf/codeofconduct/