[epage]

I don't know about OP but you don't even need to go to the level of checked exceptions, with their pain.

In Python, you are encouraged to follow Easier-to-Ask-Permission-than-Forgiveness and catch specific exceptions. Doing either / both requires you actually know what exceptions to catch so you don't hide bugs. The problem is that the docs rarely mention the expected exceptions. You have to resort to discovering them experimentally and hope that that exception was an intended part of the API contract and not an implementation detail.

[wyldfire]

IMO package authors should document the exceptions that they throw.

The Python exception hierarchy is not as good as I'd like. It should be harder to match NameError, AttributeError, etc because there's rarely a sane way to handle those.

People often write code expecting to "handle" exceptions but usually end up masking design defects. Most of the time you can only sanely handle a handful of exceptions way back at the base of the stack. And the handling at that level is usually "log" and/or "limited backoff/retry mechanism". Most of the code you're writing shouldn't do much with exceptions other than perhaps add context and re-throw.

[yxhuvud]

Not to mention old craft like old style exceptions that for some reason hasn't been cleaned out. Python always choose strict backwards compatibily instead of creating aliases to mimic the old behavior with new standard behaviour which make certain old libraries a minefield.