At 11:43 PM 7/30/2005 +1000, Nick Coghlan wrote:
Here's a fairly minimal proposal, which is closer to the existing 2.4 structure:
Raisable (formerly Exception) +-- CriticalException (new) +-- KeyboardInterrupt +-- MemoryError +-- SystemError +-- ControlFlowException (new) +-- GeneratorExit +-- StopIteration +-- SystemExit +-- Exception (formerly StandardError) +-- AssertionError +-- AttributeError +-- ImportError +-- TypeError +-- WeakReferenceError (formerly ReferenceError)
I like this a lot, and a good bit of it could actually be done in 2.5, apart from the Exception/StandardError move, assuming also that the renamed errors were also available under their old names. We could probably go so far as to add Raisable to the hierarchy, but I don't think we could actually get quite to your proposed structure without breaking any programs. On the other hand, if we introduce CriticalException and ControlFlowException in 2.5 (inheriting from Exception), and create a new Error base for StandardError, then promote subclassing and catching it instead of Exception, then there will be less to do in 3.0. So, my thoughts for the 2.x series are:
Exception CriticalException ControlFlowException Error StandardError
with the children of these being as you've proposed. Now, "except Error:" would be the replacement for a bare except in most cases, and we would recommend subclassing one of the three Exception subclasses instead of Exception itself, maybe even introduce a PendingDeprecationWarning for direct Exception subclasses outside the exceptions module, with a DeprecationWarning in 2.6 and beyond.
Note that subclassing Error instead of Exception won't hurt any programs that already catch Exception, and if they have to deal with libraries that haven't made the move, they can always use this pattern:
except (CriticalException,ControlFlowException): raise except: # whatever