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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
