PEP 484 introduced type hints, at this time documenting exceptions was left to docstrings. I seek to suggest a reason this feature might be desirable along with how it might be used. Error handling in python does an excellent job of keeping the error-path out of the way when writing the normal flow of logic, however for larger code bases it is not always clear what exceptions may be caused by calling existing code. Since these cases are easily missed they may reach a higher level than intended ...
This is a discussion on Python’s forums about adding something akin to a throws keyword in python.
Yes, but not because the goal of having exceptions in types is bad, rather Java’s type system isn’t advanced enough to support the ideal solution here.
Scala 3 is working on experimental capture checking capabilities, which allows functions to express certain capabilities (file access, networking, db, etc.), and CanThrow capabilities (e.g exceptions at the type level) are one reification of this.
The CanThrow docs I linked have a good introduction into why Java checked exceptions are bad, and how Scala’s alternative is far better. Essentially it comes down to a lack of polymorphism in checked exceptions. In practice this means they’re incredibly verbose outside of simple usecases, and with a very easy escape hatch (RuntimeException), you don’t even get the guarantee of knowing a function without checked exceptions doesn’t throw.
Python will also have this latter issue. Python’s “typing” in general has this issue actually. Types aren’t validated unless you use an external tool, and even then Any is a leaky abstraction that can hide any level of typing errors, unlike in properly typed languages where it’s not leaky. You need it to be leaky in gradually typed environments, or you wouldn’t be able to use a ton of the Python ecosystem, but this vastly reduces the effectiveness of the typing solution.
I don’t know if Python’s solution here will address the lack of polymorphism that Java’s solution has, I’ll have to look into it more.
Yes, but not because the goal of having exceptions in types is bad, rather Java’s type system isn’t advanced enough to support the ideal solution here.
Scala 3 is working on experimental capture checking capabilities, which allows functions to express certain capabilities (file access, networking, db, etc.), and CanThrow capabilities (e.g exceptions at the type level) are one reification of this.
The CanThrow docs I linked have a good introduction into why Java checked exceptions are bad, and how Scala’s alternative is far better. Essentially it comes down to a lack of polymorphism in checked exceptions. In practice this means they’re incredibly verbose outside of simple usecases, and with a very easy escape hatch (RuntimeException), you don’t even get the guarantee of knowing a function without checked exceptions doesn’t throw.
Python will also have this latter issue. Python’s “typing” in general has this issue actually. Types aren’t validated unless you use an external tool, and even then
Anyis a leaky abstraction that can hide any level of typing errors, unlike in properly typed languages where it’s not leaky. You need it to be leaky in gradually typed environments, or you wouldn’t be able to use a ton of the Python ecosystem, but this vastly reduces the effectiveness of the typing solution.I don’t know if Python’s solution here will address the lack of polymorphism that Java’s solution has, I’ll have to look into it more.