On 7/30/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > 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 > > If we leave Exception at the top of the hierarchy for Py3k, and use Error to > replace StandardError, the hierarchy could look like this: > > Exception > +-- ControlFlowException (new) > +-- GeneratorExit > +-- KeyboardInterrupt > +-- StopIteration > +-- SystemExit > +-- CriticalError (new) > +-- MemoryError > +-- SystemError > +-- Error (formerly StandardError) > +-- AssertionError > +-- AttributeError > +-- ImportError > +-- TypeError > +-- WeakReferenceError (formerly ReferenceError) > > 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. >
I can live with this, but that will require Guido's stamp of approval. > So the question is whether or not the Raisable/Exception combination is liked > enough that we want to dance through the requisite hoops to get there. > > Notice that I've classified KeyboardInterrupt as user-initiated control flow > and put it under ControlFlowException above. This means that everything under > CriticalError and Error actually ends with the word 'Error'. > I don't know if I like this change in inheritance. While we do tend to use KeyboardInterrupt as a way to kill a program, is that really control flow, or a critical exception that the program needs to stop because an serious event occurred? I prefer the latter explanation. -Brett _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
