[mannykannot]

Which just underscores the point that this is mostly software engineering theater. If your goal is a system in which all exceptions are explicitly and appropriately handled, your first mistake was picking Python.

I propose a rider to the PEP in which implementation will be deferred until its proponents can correctly affirm that the library reference lists, for each function and method, every exception it might throw.

[zahlman]

>If your goal is a system in which all exceptions are explicitly and appropriately handled, your first mistake was picking Python.

No, the goal is a system in which the code correctly indicates which exceptions it's intended to handle, and doesn't accidentally handle the wrong exceptions because the developer was either lazy or misinformed about the semantics (perhaps due to experience with a different programming language).

[mannykannot]

> ...and doesn't accidentally handle the wrong exceptions...

What support does Python offer, to the author of a function, for determining what would be the wrong exceptions for it to handle? How, in Python, does the author of a function signal, to the functions she is calling, which exceptions they should not handle? As I alluded to in my previous post, the Python language and documentation does not even give programmers a good accounting of what exceptions the library functions might throw.

[zahlman]

The point was about how the set of exceptions handled by `except:` might not match what the programmer expects, especially a programmer coming from a different language. It's not about knowing what kinds of exception the code in the `try` could raise and it isn't about telling a called function what to do.

Other languages, notably Java, have tried the "functions document what they can raise" idea. Everyone seems to hate the result.