On 5/1/2020 9:21 AM, André Roberge wrote:
On Fri, May 1, 2020 at 10:15 AM Rhodri James <rho...@kynesim.co.uk
<mailto:rho...@kynesim.co.uk>> wrote:
On 01/05/2020 07:48, Ram Rachum wrote:
> There are 2 reasons I want this:
>
> 1. When I'm writing a try..except clause, I want to catch a specific
> exception like MissingArgumentsError rather than ValueError or
TypeError.
> They're too ubiquitous. I don't want some other unexpected failure
> producing the same ValueError and triggering my except clause.
If you want to catch MissingArgumentsError, you're doing something
really weird. I'm trying to think of a realistic example and failing.
This type of error is already caught and identified by Python as a
TypeError in at least two different situations with the following
(generic) error messages:
X takes Y positional arguments but Z was given
X missing 2 required positional arguments: Y and Z
The fact that two such messages exist is indicative that this type of
error do occur in realistic code.
So, in theory, one could think of extracting these two subcases of
TypeError into a new exception subclass; personnally, I think that the
current error messages are sufficient and adding a new exception
subclass for them would just make the exception handling code more
complicated than necessary.
But the question is: why would you actually catch these different
exception types, and what would you do when you caught them? There's
actual code that checked for errno on an IOError, which is why it was
easy to say that adding FileNotFoundError, etc. would be an improvement.
Where's the code that catches (or wants to catch) MissingArgumentsError?
I do think that every exception subclass that anyone wants to add is
going to go through a case-by-case scrutiny. We're not just going to say
"let's add a lot more exceptions!".
Eric
André Roberge
> 2. When I get an error, especially from some shitty corporate
system that
> truncates the traceback, I want to get as many hints as possible
about what
> went wrong.
Then you should read the exception reason. You're still going to
have
to think about what your program logic error is, and a separate
exception is going to be less use than an explanatory text string.
--
Rhodri James *-* Kynesim Ltd
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
<mailto:python-ideas@python.org>
To unsubscribe send an email to python-ideas-le...@python.org
<mailto: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/4ZKBKMGTVUDL5G5B2ZOCEIYISOBSKAZF/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
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/OER543LOXANLUUBUYSLKNBYO6EXYJIFA/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
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/K5ABN2MQNBSZNSNYAJVQD2WE7RDLY6P7/
Code of Conduct: http://python.org/psf/codeofconduct/
