On Sat, Sep 26, 2020 at 8:48 AM Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: > > On Fri, 25 Sep 2020 at 22:05, Chris Angelico <ros...@gmail.com> wrote: > > > > On Sat, Sep 26, 2020 at 6:56 AM Oscar Benjamin > > <oscar.j.benja...@gmail.com> wrote: > > > > > > There are many common bugs that arise as a result of exceptions that > > > are overlooked. There are also often simple ways to rewrite the code > > > so that it becomes exception free. For example in sympy: > > > > > > if x.is_positive: # never raises (excepting bugs) - False if > > > indeterminate > > > if x > 0: # raises if indeterminate > > > > The novice believes that his ultimate goal is to stop the program from > > crashing. If "exception free" is your goal, then sure, this feature > > will certainly help you. I don't want Python to have language support > > for something that is primarily aimed at helping novices to remain > > forever novices. > > Yeah, because real professionals write applications that spew out > tracebacks to their users for perfectly valid inputs and real users > love that :) > > There are good reasons for writing your code in such a way that it > handles all cases rather than blowing up. Of course if you can't > handle all cases then that's one good reason for raising an exception.
That's something you do at a single location, usually - an error boundary. There are points in the code where it's correct to absorb and log all errors, but what that really means is that you're handling Exception (or BaseException) - you still don't need to enumerate every possible exception and you don't want to. I still don't know of ANY situation in Python where I have wanted a full list of every exception something might raise. > The way that I would propose is this: > > Yes, g can possibly raise any exception class. As you say it's not > generally possible to verify that arbitrary Python code can not raise > any exception outside of a nontrivial set (BaseException). > > However g can not raise any exception from a function that was > explicitly annotated as raising that exception. If some function h is > annotated as raising FooError then a FooError from h will not arise > from calling g. > I'm not sure I follow. Maybe some example code? Are you saying that, if g calls h and h is declared as raising FooError, g must be declared as raising FooError or must catch it, but any other exception is fair game? Very confused and still don't see any benefit here. ChrisA _______________________________________________ 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/PCLEVTHFBKQEDNSPXDTIHAKITD6UVF6H/ Code of Conduct: http://python.org/psf/codeofconduct/
