[Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0

[Brett Cannon]

On 8/3/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
> On 8/3/05, Brett Cannon <bcannon at gmail.com> wrote:
> > On 8/3/05, Guido van Rossum <gvanrossum at gmail.com> wrote:
> > > So here's a radical proposal (hear the scratching of the finglernail
> > > on the blackboard? :-).
> > >
> > > Start with Brett's latest proposal.
> >
> > Including renaming (I want to know if you support the renamings at
> > all, if I should make them more of an idea to be considered when we
> > get closer to Python 3.0, or just drop them) and the new exceptions?
> 
> Most of the renamings sound fine to me.
> 

OK, great.  I will leave in the new names and the new exceptions.

> > > Goal: keep bare "except:" but
> > > change it to catch only the part of the hierarchy rooted at
> > > StandardError.
> >
> > Why the change of heart?  Backwards-compatibility?  Way to keep
> > newbies from choosing Raisable or such as what to catch?
> 
> The proposal accepts that there's a need to catch "all errors that are
> reasonable to catch": that's why it separates StandardError  from the
> root exception class.
> 
> So now we're going to recommend that everyone who was using bare
> 'except:' write 'except StandardError:' instead.
> 
> So why not have a default?
> 

Because you can easily write it without a default.

> Because of EIBTI?
> 

Don't know the acronym (and neither does acronymfinder.com).

> Seems a weak argument; we have defaults for lots of things.
> 

OK.  I was fine with bare 'except' clauses to begin with so this is
not a huge point of contention for me personally.

[SNIP]

> > So just ditch StandardError, which is fine by me, or go with Nick's v2
> > proposal and have all pre-existing exceptions inherit from it?  I
> > assume the latter since you said you wanted bare 'except' clauses to
> > catch StandardError.
> 
> What do you think? Of course the critical and control flow ones should
> *not* inherit from it.
> 

Well, Nick and Jame's point of tweaking the names so that they more
reflect what people expect instead of what they are meant to actually
be is interesting.

But, in terms of backwards-compatibility, Exception/StandardError is
most exacting in terms of matching what already exists.  But with
renamings I don't know how critical this kind of low-level
backwards-compatibility is critical.

Personally I just prefer the names Exception/StandardError for
unexplained aesthetic reasons.

> [...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.
> 

OK.  I will then also leave ControlFlowException as-is.

> > > - Make Warning a subclass of Exception.
> > >
> > > I'd want the latter point even if the rest of this idea is rejected;
> > > when a Warning is raised (as opposed to just printing a message or
> > > being suppressed altogether) it should be treated just like any other
> > > normal exception, i.e. StandardError.
> >
> > Since warnings only become raised if the warnings filter lists it as
> > an error I can see how this is a reasonable suggestion.  And if bare
> > 'except' clauses catch StandardError and not Exception they will still
> > propagate to the top unless people explicitly catch Exception or lower
> > which seems fair.
> 
> Unclear what you mean; I want bare except; to catch Warnings! IOW I
> want Warning to inherit from whatever the thing is that bare except:
> catches (if we keep it) and that is the start of all the "normal"
> exceptions excluding critical and control flow exceptions.
> 

OK, that squares that one away.  And it makes sense since you can view
Warnings as even less critical exceptions than the non-control and
non-critical exceptions and thus should be caught by a default
`except' clause.

-Brett