On Feb 18, 2014, at 7:26, Alexander Belopolsky <alexander.belopolsky@gmail.com> wrote:

On Tue, Feb 18, 2014 at 10:13 AM, MRAB <python@mrabarnett.plus.com> wrote:
>
> Another possibility would be to say that a bare except in an expression
> catches only certain "expression-oriented" exceptions, e.g. ValueError.
> The simplest way to do that would be to make them subclasses of an
> ExpressionError class.

+1

>
> The question then becomes one of which
> exceptions are "expression-oriented"...

Here is my attempt to answer:

- ArithmeticError
- AttributeError
- LookupError
- TypeError ?
- ValueError ?

And Chris Angelico gave an overlapping but different list by scanning the built-in exception types.

The fact that neither of them mentioned KeyError or IndexError, which are the two paradigm cases that brought up the proposal in the first place, implies to me that any attempt to define a collection of "expression errors" is going to be as hard and as contentious as coming up with a syntax. So, if the point of it was to allow us to come up with a new syntax that only handles one exception type, I don't think it's a promising avenue.

If people do want to follow this, one thing to consider: we don't have to fiddle with the exception hierarchy; you can always override issubclass/isinstance by either using an

ABC, or doing the same thing ABCMeta does. That would allow someone who wanted to catch some type of error that isn't usually considered an "expression error" but is commonly raised in expressions in their particular project to add that error.