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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/WL3EIAOWBNWHD4IAKX7TOSHBJ75UKXJF/
Code of Conduct: http://python.org/psf/codeofconduct/
