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

Phillip J. Eby pje at telecommunity.com
Sun Jul 31 18:49:32 CEST 2005


At 12:12 PM 7/31/2005 -0400, James Y Knight wrote:
>On Jul 30, 2005, at 8:57 PM, Nick Coghlan wrote:
> > I wouldn't mind using Exception/Error instead of Raisable/Exception
> > - and it
> > seriously reduces the pain of making this transition. Indeed, most
> > of it
> > becomes doable within the 2.x series - the only tricky parts are
> > semantic
> > changes involved with moving the KeyboardInterrupt, MemoryError and
> > SystemError out from under StandardError, and moving EOFError under
> > IOError.
>
>It seems to me that it *increases* the pain of transition.
>I do not see any reason why adding a new class above the current
>hierarchy causes any problems. However, changing the recommended base
>class for user-defined exceptions from "Exception" to "Error" will
>cause problems for *every* library.

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.


>Moving KeyboardInterrupt, MemoryError, and SystemError out from under
>Exception will be a backwards compatibility issue, but that's the
>case in all proposals.

Actually, in my tweak of Nick's proposal they're still Exception 
subclasses, so nothing breaks.


>Additionally, I predict the pain from doing
>that will be minor. In cases where apps want to catch *all*
>exceptions, they must already use "except:" instead of "except
>Exception:", as not all exceptions derive from Exception. And
>catching the above three in any circumstance other than when
>explicitly mentioned and when wanting to catch every exception is
>probably wrong. So moving them will probably not cause many programs
>to malfunction.

In which case, maybe we should just implement Nick's full proposal, since 
the only thing that it would break is code that uses "except Exception:" to 
catch SystemExit or StopIteration.



More information about the Python-Dev mailing list