On Mon, Oct 12, 2020 at 6:52 PM <jmwar...@gmail.com> wrote:
> Greg Ewing wrote:
> > > You can reduce the amount of boilerplate by doing something
> > like this:
> > class MySpecialException(Exception):
> > pass
> > def handle_my_special_exception(a, b, c, d, e, f):
> > ....
> > try:
> > if some_test_that_fails(variables):
> > raise MySpecialException(a, b, c, d, e, f)
> > except MySpecialException as e:
> > if not handle_my_special_exception(*e.args):
> > raise
>
> Yeah, I could remove some of the argument assignment, but I think your
> example points out even more strongly how useless that class was in
> managing the exception. It is literally just a name that I am forced to
> define outside the flow of logic.
well, yes, if that's all you do. But using a class allows you to take
advantage of the class hierarchy:
class SpecialValueError(ValueError):
pass
So that will now be caught by either:
except SpecialValueError
or
exceptValueError
or
exceptException
But if you can't define that name "Outside the flow of logic" -- where the
heck ARE you going to define it? As a rule, Exceptions are caught somewhere
different than they are raised -- so how does the catching code know what
name to catch?!?
The other advantage of custom Exceptions is that you can put whatever extra
logic or attributes, or whatever you want in them. If you don't need to do
any of that, and you don't want to define a name "outside the logic", then
why not just use an built in exception? You can still tack on any extra
data you want when you raise it:
In [3]: try:
...: raise ValueError("a message", "other", "data")
...: except ValueError as err:
...: print("caught my nifty Exception, with extra data:")
...: print(err.args)
...:
caught my nifty Exception, with extra data:
('a message', 'other', 'data')
If exceptions had less boilerplate they might get used more often with more
> description. It would be great to get a KeyError like this:
>
> try:
> if c[name] == 'fried chicken':
> eat(c[name])
> except KeyError.missingKey(key):
> c[key] = getMoreChicken()
>
> A little contrived since the key name is available in the same scope, but
> the clarity of passing a variable along with the exception in a function
> like syntax makes the handler more obvious and the ease of throwing these
> named returns would likely lead to more exception handling instead of
> checking first then doing it.
Can you explain what this is doing? what namespace i"key" in this case??
where did it come from? And a KeyError already has they missing key stored
in it:
In [10]: try:
...: d['fred']
...: except KeyError as err:
...: print(f"The key: {err.args[0]} is not in the dict")
...:
The key: fred is not in the dict
So what are we getting here?
> Even without the parameters, this on the fly exception definition would be
> useful and encourage code clarity.
> You could do things like:
>
>
> try:
> r = requests.get(some_url)
> except HTTPError.notFound(url):
> print(f"{url} not found. Try another one")
> except HTTPError:
> print(f"Unknown HTTP Error that doesn't obviously advertise its self!
> PANIC")
> raise
>
I'm confused, can't you already do that kind of thing with requests?
Of course, again, looking at the requests code shows just how much
> boilerplate these things take up. The base class RequestException has some
> code in it but then there are 22 derived exceptions. So many classes
> defined just to give a name to an exception and none of them have special
> parameters guaranteed in the exception that might help you better handle
> what happened.
>
Personally, that's why I tend to use the buillt in exceptions most of the
time. But anyway, of those names were not defined in the requests package,
where WOULD they be defined?
How could you (or Python) possibly know what the heck:
HTTPError.notFound
was???
If the idea is to get the url that wasn't found, it would have to be in the
Exception object somewhere, and there would have to be code tha put it
there. Which is what we can already do with Exceptions -- still confused
here.
-CHB
> _______________________________________________
> 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/KNGACZYDMKYYD7TDXRBE2LOZWQJHIWGK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
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/2VEZLJMJ57XH5MFEM4ONHSVHQC2CKN67/
Code of Conduct: http://python.org/psf/codeofconduct/
