On Fri, 25 Sep 2020 at 18:59, Chris Angelico <ros...@gmail.com> wrote: > > On Sat, Sep 26, 2020 at 2:32 AM Oscar Benjamin > <oscar.j.benja...@gmail.com> wrote: > > I do agree but maybe that suggests a different role for annotated > > exceptions in Python. Rather than attempting to enumerate all possible > > exceptions annotations could be used to document in a statically > > analysable way what the "expected" exceptions are. A type checker > > could use those to check whether a caller is handling the *expected* > > exceptions rather than to verify that the list of *all* exceptions > > possibly raised is exhaustive. > > > > Consider an example: > > > > def inverse(M: Matrix) -> Matrix: raises(NotInvertibleError) > > if determinant(M) == 0: > > raise NotInvertibleError > > rows, cols = M.shape > > for i in range(rows): > > for j in range(cols): > > ... > > > > Here the function is expected to raise NotInvertibleError for some > > inputs. > > Please no. Once again, this will encourage "handling" of errors by > suppressing them. Don't have anything that forces people to handle > exceptions they can't handle.
Why would anyone be forced to "handle" the exceptions? The suggestion (which you've snipped away) was not that it would be a type-checking error to call the inverse function without catching the exception. It only becomes a type-checking error if a function calls the inverse function and claims not to raise the exception. The checker just verifies the consistency of the different claims about what is raised. Oscar _______________________________________________ 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/TPGC6DJUSOHJN32UFYYRJRS53CZFXFPV/ Code of Conduct: http://python.org/psf/codeofconduct/
