On Wed, Feb 19, 2014 at 2:13 AM, MRAB
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. The question then becomes one of which exceptions are "expression-oriented"...
Easier than fiddling with class inheritance would be to make ExpressionError into a tuple of exception types - at least for testing purposes. If this _is_ to be done, I would definitely advocate having that name (or some equivalent) as a built-in, so it's straight-forward to either manipulate it or use it in a statement-except. But you're absolutely right that the question of which ones are expression-oriented would be a big one. I could imagine catching (ValueError, Unicode{En,De}codeError, AttributeError, EOFError, IOError, OSError, LookupError, NameError, ZeroDivisionError) and that's just from a quick skim of the built-in names. Would you consider making a tuple like that and then using "except CommonErrors:" all over your code? Or more to the point, if it were really convenient to do that, would it improve your code? ChrisA