On Tue, Apr 20, 2021 at 2:15 PM srkunze@mail.de <srkunze@mail.de> wrote:
So, forgive me my relatively simple mental model about ExceptionGroup. I still try to create one for daily use.
As noted in the discussion, an EG provides a way to collect exceptions from different sources and raise them as a bundle. They have no apparent relation up until this point in time (for whatever reason they have been separate and for whatever reason they are bundled now). The result would be a tree graph in any case.
A usual datastructure for a tree is to store all child nodes at the parent node.
That was the idea behind the content of BaseException.__group__: it’s the list of child exceptions bundled at a specific point in time and raise as such a bundle. So all exceptions could become EGs with the additional semantics you‘ve described in the PEP.
Illustrative Example:
bundle_exc.__group__ [IOError(123), RuntimerError(‘issue somewhere’)]
I was wondering what of the PEP could be removed to make it simpler and more acceptable/less confusing (also looking at reactions from Twitter etc.) and I found these additional classes to be a part of it. Additionally, I fail to see how to access these bundled exceptions in an easy manner like __cause__ and __context__. (As the PEP also referring to them). So, I removed the classes and added a regular attribute.
This seems more confusing to me too. Instead of having a single ExceptionGroup class, you're suggesting that all exceptions should effectively become ExceptionGroups. I know what ExceptionGroup([ValueError]) means -- it means there was a ValueError, and it got put in a group, so it should probably be handled the same way as a ValueError. I have no idea what a KeyError([ValueError]) would mean. Is that a KeyError or a ValueError? Adding flexibility doesn't necessarily make things simpler :-) -n -- Nathaniel J. Smith -- https://vorpus.org