On 2021-09-30 09:25, Soni L. wrote:
these then get added to the function, similar to e.g. default args. when an exception is thrown*, the VM then checks these and converts relevant exceptions into RuntimeError, e.g.:
def foo(): raise Bar def baz() with Bar: foo() baz()
would make a RuntimeError, because foo raised a Bar and the VM sees that Bar is in baz's with.
*except "raise" opcodes SKIP checking these (within the context of the function), so the following:
def baz() with Bar: raise Bar baz()
raises a Bar, not a RuntimeError from a Bar.
I think this illustrates what Chris said before about "you want exceptions to not be exceptions". The way exceptions work is that they propagate up the call stack. What you're describing is a mechanism whereby a Bar exception raised "directly" in the lexical function definition would behave differently from one raised deeper in the call stack. I think that breaks some pretty basic assumptions about how exceptions work, and I wouldn't support such a change. -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown