On 2020-04-09 8:48 a.m., Rhodri James wrote:
[Muchly snipped]
On 09/04/2020 12:27, Soni L. wrote:
To put it simple, unpacking raises ValueError:
But if the iterator raises ValueError, there's no way to tell it
apart from the unpacking:
I don't see how this is any different from any other case when you get
the same exception for different errors. If for some reason you
really care, subclass ValueError to make a finer-grained exception.
And the workaround for this is a bit ugly. We already convert e.g.
StopIteration into RuntimeError in many cases, why can't we do so
here too?
Surely the correct "workaround" is not to do the thing that raises the
exception?
Technically, I consider it a bug that bugs can shadow API-level
exceptions. Any API defining API-level exceptions must carefully control
the exceptions it raises. In this case I'd like to use the ValueError
from the iterator unpacking API, on my API. But since the iterator
unpacking API doesn't control its exceptions, this just does a great job
of masking bugs in the code instead.
Equally, anything doing computation in __get__ should not propagate
LookupError except where explicitly intended. And that's not how those
things are often implemented, unfortunately. There's a reason ppl
complain so much about certain frameworks "eating all the exceptions".
They use exceptions as part of their API but let user code raise those
API-level exceptions, which, because they're part of the API, get
handled somewhere.
_______________________________________________
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/XEPFBGSNPNUZ7KR7WT4TDHU2HM5BQ5WQ/
Code of Conduct: http://python.org/psf/codeofconduct/
