[Python-Dev] Exception Reorg PEP revised yet again

[Brett Cannon]

On 8/8/05, Raymond Hettinger <python at rcn.com> wrote:
> [Brett Cannon]
> > At this point the only
> > changes to the hierarchy are the addition of BaseException and
> > TerminatingException, and the change of inheritnace for
> > KeyboardInterrupt, SystemExit, and NotImplementedError.
> 
> TerminatingException
> --------------------
> 
> The rationale for adding TerminatingException needs to be developed or
> reconsidered.  AFAICT, there hasn't been an exploration of existing code
> bases to determine that there is going to be even minimal use of "except
> TerminatingException".
> 
> Are KeyboardInterrupt and SystemExit often caught together on the same
> line and handled in the same way?
> 

The problem with existing code checking for this situation is that the
situation itself is not the same as it will be if bare 'except's
change::

 try:
   ...
 except:
   ...
 except TerminatingException:
   ...

has never really been possible before, but will be if the PEP goes forward.

> If so, isn't "except TerminatingException" less explicit, clear, and
> flexible than "except (KeyboardInterrupt, SystemExit)"?  Do we need a
> second way to do it?
> 

But what if we add other exceptions that don't inherit from Exception
that was want to typically propagate up?  Having a catch-all for
exceptions that a bare 'except' will skip that is more explicit than
``except BaseException`` seems reasonable to me.  As Nick said in
another email, it provides a more obvoius self-documentation point to
catch TerminatingException than ``(KeyboardInterrupt, SystemExit)``,
plus you get some future-proofing on top of it in case we add more
exceptions that are not caught by a bare 'except'.

> Doesn't the new meaning of Exception already offer a better idiom:
> 
>    try:
>       suite()
>    except Exception:
>       log_or_recover()
>    except:
>       handle_terminating_exceptions()
>    else:
> 
> Are there any benefits sufficient to warrant yet another new built-in?
> Does it also warrant violating FIBTN by introducing more structure?
> While I'm clear on why KeyboardInterrupt and SystemExit were moved from
> under Exception, it is not at all clear what problem is being solved by
> adding a new intermediate grouping.
> 
> The PEP needs to address all of the above.  Right now, it contains a
> definition rather than justification, research, and analysis.
> 
> 
> 
> WindowsError
> ------------
> 
> This should be kept.  Unlike module specific exceptions, this exception
> occurs in multiple places and diverse applications.  It is appropriate
> to list as a builtin.
> 
> "Too O/S specific" is not a reason for eliminating this.  Looking at the
> codebase there does not appear to be a good substitute.  Eliminating
> this one would break code, decrease clarity, and cause modules to grow
> competing variants.
> 

I unfortunately forgot to add that the exception would be moved under
os, so it would be more of a renaming than a removal.

The reason I pulled it was that Guido said UnixError and MacError
didn't belong, so why should WindowsError stay?  Obviously there are
backwards-compatibility issues with removing it, but why should we
have this platform-specific thing in the built-in namespace?  Nothing
else is platform-specific in the language until you go into the
stdlib.  The language itself is supposed to be platform-agnostic, and
yet here is this exception that is not meant to be used by anyone but
by a specific OS.  Seems like a contradiction to me.

> After the change, nothing would be better and many things would be
> worse.
> 
> 
> 
> NotImplementedError
> -------------------
> Moving this is fine.  Removing unnecessary nesting is a step forward.
> The PEP should list that as a justification.
> 

Yay, something uncontraversial!  =)

> 
> 
> Bare excepts defaulting to Exception
> ------------------------------------
> 
> After further thought, I'm not as sure about this one and whether it is
> workable.  The code fragment above highlights the issue.  In a series of
> except clauses, each line only matches what was not caught by a previous
> clause.  This is a useful and basic part of the syntax.  It leaves a
> bare except to have the role of a final catchall (much like a default in
> C's switch-case).  If one line uses "except Exception", then a
> subsequence bare except should probably catch KeyboardInterrupt and
> SystemExit.  Otherwise, there is a risk of creating optical illusion
> errors (code that looks like it should work but is actually broken).
> I'm not certain on this one, but the PEP does need to fully explore the
> implications and think-out the consequent usability issues.
> 

This is Guido's thing.  You will have to convince him of the change. 
I can flesh out the PEP to argue for which ever result he wants, but
that part of the proposal is in there because Guido wanted it.  I am
just a PEP lackey in this case.  =)

> 
> > And once that is settled I guess it is either time for pronouncement
> > or it just sits there until Python 3.0 actually starts to come upon
> > us.
> 
> What happened to "don't take this too seriously, I'm just trying to get
> the ball rolling"?
> 

Nothing, it's called writing the email when I was tired and while I
was trying to fall asleep realizing what I had done.  =)

It still needs to go out to c.l.py and will probably sit for a long
while unpronounced.  That's the reason I was saying that the
transition plan needs to be fleshed out with 2.x, 2.x+1 version
numbers instead of concrete ones like 2.5 .

-Brett