[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0

[James Y Knight]

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:
>
>     try:
>         ...
>     except (CriticalException,ControlFlowException):
>         raise
>     except:
>         ...
>
> 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  
somewhat broken.

James