-
Notifications
You must be signed in to change notification settings - Fork 4
A case for raise* #7
Comments
We can even construct a relatively realistic example for this: ignoring all |
Alternatively, we could have a split operation like in Trio's MultiError v2 design, which takes a predicate and returns two MultiError instances with the same substructure. Then if we were to use that same split operation to split off the exceptions matching the except clause, The split operation should be recursive, e.g. (untested): UPDATED class MultiError(BaseException):
def split(self, pred):
a = []
b = []
for e in self.inner_exceptions:
if isinstance(e, MultiError):
a1, b1 = e.split(pred)
if a1:
a.append(a1)
if b1:
b.append(b1)
elif pred(e):
a.append(e)
else:
b.append(e)
return group(a), group(b) where def group(excs):
if excs:
return ExceptionGroup(excs)
else:
return None |
ISTM that we don't really have a choice in the matter - the split operation has to preserve the nested structure because otherwise the tracebacks are wrong. Exceptions that belong to the same ExceptionGroup share the traceback of the group, and then they split. If we offer a flatten operation for Exception groups, then it needs to also set all the tracebacks to None. |
Related to the above - I think this example from the current document is incorrect. The KeyError should not be merged into the EG of the TypeError, because it doesn't have that EG's traceback, and it as the matched part of the EG as its context.
|
I'm closing this because I think we settled on preserving the structure of an EG throughout, and we don't provide any iteration/flattening apis for now (we can reconsider when a use case for them turns up). |
This builds on top of what's defined in here (permalink)
According to the latest spec, using
raise e
orraise
inside anexcept*
clause wouldn't flatten the tree of errors, e.g.:But when raising an
ExceptionGroup()
instance manually the tree would be flattened:This makes the case of "I only want to handle one or few exceptions from the group and re-raise all others without flattening them" a bit problematic. But what if we could use
raise *
syntax for that:The text was updated successfully, but these errors were encountered: