[Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Nick Coghlan
ncoghlan at gmail.com
Sat Jul 30 10:13:31 CEST 2005
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
> StopIteration?)
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:
http://dictionary.reference.com/search?q=raisable
> 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.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
More information about the Python-Dev
mailing list