
On Wed, Mar 3, 2021 at 10:39 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 4/03/21 5:37 am, Paul Moore wrote:
frameworks and libraries typically have to interact with other users' code, and there the contract has changed from "do what you like in your code and I'll cope" to "do what you like in your code as long as you don't let an exception group escape, and I'll cope"... And I have to change *my* code to get the old contract back.
Seems to me this whole issue would go away if the ordinary except statement were to look inside ExceptionGroups.
In other words, the only difference between except and except* would be that multiple except* clauses can be run, whereas only one except clause will run (the first one that matches something in the ExceptionGroup).
Is there any good reason not to do things that way?
That's an interesting idea. Do you mean that one exception gets handled and the rest of the group is reraised? Or discarded? The value of sys.exc_info() (and the e in "except T as e:") needs to be a single naked exception. So if there is more than one match in the group we would need to pick one (let's say the first in DFS order). If we do this, then we have this situation. Before ExceptionGroups, you got to choose which of the exceptions you have is the most important, and you raised only that one. Now you raise a bunch of them and the order of the except clauses in caller's code determines which one of them counts and which ones are discarded. What do you make of that? Irit