[Python-ideas] Type hints for functions with side-effects and for functions raising exceptions

[Juancarlo Añez]

On Thu, Feb 21, 2019 at 10:34 PM Ben Rudiak-Gould <benrudiak at gmail.com>
wrote:

> > It's well documented how checked exceptions lead to bad code.
>
> Please cite a paper. I know "everyone knows" that they're bad, but
> "everyone knows" a lot of things.
>

This is one of the original interviews touching why checked exceptions were
not made part of C#:

https://www.artima.com/intv/handcuffs.html

The problem is that a code fragment should only catch exceptions that it
expects, because it won't know what to do anything else but to wrap the
exception into one of the enclosing type.

But if every type has to define a SomethingWentWrongInTypeException wrapper
exception, it's logical that all of them inherit from a standard
SomethingWentWrongException. Having done that, the type-specific generic
exceptions are of no value, because any code wanting to guard against the
unexpected will just catch SomethingWentWrongException. And that brings us
back to square one, which is letting unexpected exceptions through to
wherever a clean shutdown or restart of the subsystem can be done.

Then, if exceptions are going to be part of a type, there should be a way
to express the semantics of them (like in Eiffel), so
stack.pop();stack.push(x) doesn't have to catch StackFullException.

In the end, I think that allowing type-hints about exceptions that may be
raised is quite useful, as long as they are not checked/enforced (in the
style of Java). Many times I've missed a PyCharm hint me about the actual
exceptions a given call may actually raise.

Newer languages like Go and Swift shy away from exceptions because of the
tendency to:

try:

   # something

except:

     print('oops!)


-- 
Juancarlo *Añez*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20190221/8d596e96/attachment.html>