[Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
Brett Cannon
bcannon at gmail.com
Thu Aug 4 00:47:54 CEST 2005
On 8/3/05, James Y Knight <foom at fuhm.net> wrote:
> On Aug 3, 2005, at 3:00 PM, Guido van Rossum wrote:
> > [...brain hums...]
> >
> > OK, I'm changing my mind again about the names again.
> >
> > Exception as the root and StandardError can stay; the only new
> > proposal would then be to make bare 'except:' call StandardError.
>
> I don't see how that can work. Any solution that is expected to
> result in a usable hierarchy this century must preserve "Exception"
> as the object that user exceptions should derive from (and therefore
> that users should generally catch, as well). There is way too much
> momentum behind that to change it.
>
Oh, I bet Guido can make them change. =)
Look at it this way; going with the Raisable/Exception change and
having bare 'except's catch Exception will still lead to a semantic
change since CriticalError and ControlFlowException will not be
caught. Breakage is going to happen, so why not just do a more
thorough change that leads to more breakage?
Obviously you are saying to minimize it while Guido is saying to go
for a more thorough change. So how much more code is going to crap
out with this change? Everything under our control will be fine since
we can change it. User-defined exceptions might need to be changed if
they inherit directly from Exception instead of StandardError, which
is probably the common case, but changing a superclass is not hard.
That kind of breakage is not bad since you can easily systematically
change superclasses of exceptions from Exception to StandardError
without much effort thanks to regexes.
I honestly think the requirement of inheriting from a specific
superclass will lead to more breakage since you can't grep for
exceptions that don't at least inherit from *some* exception
universally.
-Brett
More information about the Python-Dev
mailing list