[Python-ideas] Bad code exceptions (was PEP-3151 pattern-matching)

[Mike Graham]

On Fri, Apr 8, 2011 at 1:11 PM, Guido van Rossum <guido at python.org> wrote:
> ...
>
> - Lastly, there is a bunch of standard exception types that are
> usually caused by bad code (as opposed to bad data or an environmental
> problem). This would include NameError, TypeError, AttributeError, but
> not KeyError, IndexError, ValueError. Perhaps it makes sense to
> introduce a common base class for these "bad code" exceptions? Unlike
> the other exception types, I think that the set of "bad code"
> exceptions is pretty much static; a new library module is not going to
> define raise a new kind of "bad code" exception. (But it may well
> define a new kind of "bad data" exception, and I don't think we need a
> common base class for all "bad data" or "bad state" exceptions.)
>
> --
> --Guido van Rossum (python.org/~guido)

The main usage I see for this is "ignore all exceptions except bad
programming exceptions". People try to do this now with a bare except
clause. 97% of the time, doing this is very ill-advised.

My gut reaction is that providing such a thing will encourage people
to use catchall exceptions. The penalty of making people write
"(KeyboardInterrupt, NameError, AttributeError)" when they want this
will be beneficial by a) not further complicating the exception
hierarchy, b) not encouraging catchalls, and c) making the developer
decide what they want to ignore and what they want to propagate for
borderline cases like TypeError.