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.
@sugar_in_your_tea I don’t think we should change any functionality when it comes to exception handling. Code based documentation would be great for type checking and auto-generated docs, but they can be done using annotations, not changed interfaces.
Monads are already possible, but should not be the normal way to code either. It’s clunky and difficult to understand. It might work great for some scenarios, but doesn’t for many others.
Monads are only clunky because Python doesn’t really support them.
And I agree, I don’t think we should change existing exception handling, just allow the programmer to interact with it differently. I’d love to be able to turn exceptions into monads with a little bit of syntax. Under the hood, Python would still do the try/except, but my code would use exceptions as values instead. You’d still be able to use the older try/except explicitly just like you can express a list comprehension as a generator manually, you’d just have the option to do something else if it’s cleaner in your project.
That said, exceptions as values isn’t a hill I’m willing to die on, but I will push against “throws” being added, and optional chaining is a hill I’m willing to die on.
@sugar_in_your_tea I don’t think we should change any functionality when it comes to exception handling. Code based documentation would be great for type checking and auto-generated docs, but they can be done using annotations, not changed interfaces.
Monads are already possible, but should not be the normal way to code either. It’s clunky and difficult to understand. It might work great for some scenarios, but doesn’t for many others.
Monads are only clunky because Python doesn’t really support them.
And I agree, I don’t think we should change existing exception handling, just allow the programmer to interact with it differently. I’d love to be able to turn exceptions into monads with a little bit of syntax. Under the hood, Python would still do the try/except, but my code would use exceptions as values instead. You’d still be able to use the older try/except explicitly just like you can express a list comprehension as a generator manually, you’d just have the option to do something else if it’s cleaner in your project.
That said, exceptions as values isn’t a hill I’m willing to die on, but I will push against “throws” being added, and optional chaining is a hill I’m willing to die on.