[Python-Dev] Exception Reorg PEP revised yet again

[Nick Coghlan]

Raymond Hettinger wrote:
> 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?  

Yes, to avoid the current overbroad inheritance of "except Exception:" by 
intercepting and reraising these two terminating exceptions.

> If so, isn't "except TerminatingException" less explicit, clear, and
> flexible than "except (KeyboardInterrupt, SystemExit)"?

No, TerminatingException makes it explicit to the reader what is going on - 
special handling is being applied to any exceptions that indicate the 
interpreter is expected to exit as a result of the exception. Using "except 
(KeyboardInterrupt, SystemExit):" is less explicit, as it relies on the reader 
knowing that these two exceptions share the common characteristic that they 
are generally meant to terminate the Python interpreter.

> 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 main benefits of TerminatingException lie in easing the transition to 
Py3k. After transition, "except Exception:" will already do the right thing.
However, TerminatingException will still serve a useful documentational 
purpose, as it sums up in two words the key characteristic that caused 
KeyboardInterrupt and SystemExit to be moved out from underneath Exception.

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

I'm also concerned about this one. IMO, bare excepts in Python 3k should 
either not be allowed at all (use "except BaseException:" intead), or they 
should be synonyms for "except BaseException:".

Having a bare except that doesn't actually catch everything just seems wrong - 
and we already have style guides that say "except Exception:" is to be 
generally preferred over a bare except. Consenting adults and all that. . .

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.blogspot.com