[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
James Y Knight
foom at fuhm.net
Tue Aug 2 17:08:11 CEST 2005
On Jul 31, 2005, at 12:49 PM, Phillip J. Eby wrote:
> I think you're ignoring the part where most exception handlers are
> already broken. At least adding CriticalException and
> ControlFlowException makes it possible to add this:
> except (CriticalException,ControlFlowException):
> This isn't great, I admit, but at least it would actually *work*.
> I also don't see how changing the recommended base class from
> Exception to Error causes *problems* for every library. Sure, it
> forces them to move (eventually!), but it's a trivial change, and
> makes it *possible* to do the right thing with exceptions (e.g.
> except Error:) as soon as all the libraries you depend on have
> moved to using Error.
Exactly. That is the problem. Adding a new class above Exception in
the hierarchy allows everything to work nicely *now*. Recommended
practice has been to have exceptions derive from Exception for a
looong time. Changing everybody now will take approximately forever,
which means the Error class is pretty much useless. By keeping the
definition of Exception as "the standard thing you should derive from
and catch", and adding a superclass with things you shouldn't catch,
you make conversion a lot simpler. If you're not worried about
compatibility with ye olde string exceptions, you can start using
"except Exception" immediately. If you are, you can do as your
example above. And when Python v.Future comes around, "except
Exception" will be the only reasonable thing to do.
If, on the other hand, we use Exception as the base class and Error
as the thing you should use, I predict that even by the time Python
v.Future comes out, many libraries/prgrams will still have exceptions
deriving from Exception, thus making the Exception/Error distinction
More information about the Python-Dev