[Python-Dev] Exception Reorg PEP revised yet again
Brett Cannon
bcannon at gmail.com
Tue Aug 9 19:17:42 CEST 2005
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
More information about the Python-Dev
mailing list