Hi, Le 05/03/2021 à 14:46, Irit Katriel via Python-Dev a écrit : > > > Whether you have "as" or not, the value of sys.exc_info() (which is what > would be attached as the context to anything you raise in the except > block) is the same. So these are not two different cases -- the only > difference is whether or not you have a local variable set to > sys.exc_info().
I don't really understand how this contradicts the behavior I proposed (i.e. that bare "raise" raises something else than what is bound to the "as" variable). Specifically, which of the following statements are hard and unbreakable rules, even when exception groups are involved: 1) sys.exc_info() must be the same object that is bound to the "as" variable, if any; 2) sys.exc_info() must be the same object that is attached as __context__; 3) sys.exc_info() must be the same object that is raised by a bare "raise". I'd say 1 is a hard rule because both objects are visible to user code, so backwards compatibility applies. Rules 2 and 3, however, are internal to the exception handling machinery, so I'm not so sure. Cheers, Baptiste > On Thu, Mar 4, 2021 at 4:46 PM Baptiste Carvello > <devel2...@baptiste-carvello.net > <mailto:devel2...@baptiste-carvello.net>> wrote: > > Hi, > > I'll take a shoot at this, just to see how it tastes… So, let's say: > > When an exception group reaches a set of traditional "except" clauses, > those are examined one after the other, in the order they are in the > code. That way, exceptions matched by several clauses will cause the > first one to run, same as today. > > A subgroup is built with the subset of exceptions matched by the > examined clause, as the PEP specifies for "except*". If this subgroup is > None, the clause is not selected, and the next clause, if any, is > examined. On the contrary, if the subgroup contains at least one matched > exception, the clause is selected and no other clause will run (again, > same as today). Exceptions not part of the subgroup are discarded. > > The clause body is then run just once (so the boss only gets one email > about KeyboardInterrupt). If the clause uses the "as" form, the "as" > variable is bound to one exception in the subgroup, which one is > unspecified (at least for now). The other ones are discarded, except if > a bare "raise" is reached (below). > > If a bare "raise" is reached while executing the body, the selected > subgroup propagates out of the "try-except" construct. Justification: > the whole group cannot propagate, because today a bare "raise" cannot > reraise exceptions of a type not matched by the clause. However, if a > single-type exception group is handled similar to a single exception in > traditional "except" clauses, it is acceptable to let it propagate. > > So you would have: > > try: > g=BaseExceptionGroup( > [ValueError(), KeyboardInterrupt(), KeyboardInterrupt()]) > raise g > except RuntimeError: # doesn't match > log_the_error() > except KeyboardInterrupt as e: # builds s=g.subgroup(KeyboardInterrupt) > email_the_boss(e) # tells the boss of any one error > raise # reraises s > except BaseException: # would match, but doesn't run > launch_nuclear_attack() > > # BaseExceptionGroup([KeyboardInterrupt(), KeyboardInterrupt()]) > # propagates further, a traditional "except KeyboardInterrupt" > # would catch it. The ValueError is discarded. > > An interesting feature would be: when the matching clause has no "as", > "except" behaves the same as "except*", apart from the fact that only > one clause may run. > > Cheers, > Baptiste > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > <mailto:python-dev@python.org> > To unsubscribe send an email to python-dev-le...@python.org > <mailto:python-dev-le...@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/EXC6BQVHQXUXBHIEWHLSLU6FY7SJKIF3/ > Code of Conduct: http://python.org/psf/codeofconduct/ > > _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/LXAATJDDWXYYQ3P62SAZ4H7CEZGX2TUW/ Code of Conduct: http://python.org/psf/codeofconduct/
