Brett Cannon wrote:
+-- ControlFlowException (new)
While I like the idea of ControlFlowException as the "one obvious way" to break out of multiple nested loops, I'm not convinced StopIteration and GeneratorExit should be inheriting from it.
However, I'm even less sure StopIteration and GeneratorExit should be in the Exception portion of the hierarchy at all. This is particularly true of GeneratorExit - I would be very concerned if "except Exception:" were to suppress GeneratorExit. If ControlFlowException was moved up to be a peer of Exception, I'd be much happier with the idea - we would then have four major categories of raisable classes: CriticalException - something is seriously wrong ControlFlowException - an exception is being used to affect control flow in a particular way, and should be intercepted only if you know what that control flow is doing Exception - your every day, run of the mill, exceptions Warning - not really an exception.
+-- GeneratorExit (introduced by PEP 342 [PEP342]_; subclass
Definitely not. GeneratorExit was added because the following idiom prevents the use of StopIteration or a subclass to reliably terminate a generator:
try: yield itr.next() catch StopIteration: pass
+-- LookupError (better name?) +-- IndexError +-- KeyError
I don't think there is a particularly strong argument to change the name of LookupError. While Py3K *allows* backwards incompatibility, we shouldn't be gratutitous about it.
+-- TypeError +-- AttributeError (subclassing new) +-- NamespaceException (new) +-- UnboundGlobalError (new name for NameError) +-- UnboundLocalError (no longer subclasses UnboundGlobalError
which replaces NameError)
I'd actually be inclined to make AttributeError a subclass of NameError:
+-- NameError +-- AttributeError (subclassing new) +-- UnboundGlobalError (new) +-- UnboundLocalError
Current uses of NameError are replaced with UnboundGlobalError. The re-use of NameError reduces the backwards incompatibility, and also concisely summarises the common feature of these three exceptions.
RuntimeError '''''''''''' Meant to be used when an existing exception does not fit, its usefulness is consider meager in Python 2.4 [exceptionsmodule]_. Also, with the CriticalException/Exception dichotomy, Exception or CriticalException can be raised directly for the same use.
Like Guido, I believe RuntimeError is very useful for quick-and-dirty scripts. Also, gratuitous incompatibility should be avoided, even for Py3k.
Change the Name of Raisable?
It has been argued that Raisable is a bad name to use since it is not an actual word [python-dev1]_. At issue is choosing a name that clearly explains the class' usage. "BaseException" might be acceptable although the name does not quite make it as explicit as Raisable that the class is not meant to be raised directly.
I like Raisable, because it states exactly what the base class indicates: something which can be raised (i.e., used with the "raise" statement). I'm also unclear on why anyone would say it isn't an actual word:
Should Bare ``except`` Clauses be Removed?
I think Explicit Is Better Than Implicit for this one - a bare except which is not the equivalent of "except Raisable" would be quite confusing.
So long as the tutorial says that anything broader then "except Exception" is going to be wrong 99.9% of the time, I don't think there will be a problem.
Change the name of Exception?
Again, there is a strong backwards compatibility argument for keeping the name Exception for the "this is what you should normally catch" category. Mainly, there's a lot of code out there that already uses it this way. Without a compelling argument in favour of a different name, stick with Exception.