Merge in suggestions from Neal Norwitz.
- Simplified __init__ and fixed __getitem__ - Added another way to catch all exceptions sans KeyboardInterrupt and SystemExit as Python stands now (does not invalidate argument that it it needlessly explicit) - Added a diagram of how the exception hierarchy will look - Small grammar and clarification fixes
This commit is contained in:
parent
9495215f04
commit
1ac3ad11df
50
pep-0352.txt
50
pep-0352.txt
|
@ -22,10 +22,10 @@ proposes introducing a new superclass that all raised objects must
|
|||
inherit from. Imposing the restriction will allow a standard
|
||||
interface for exceptions to exist that can be relied upon.
|
||||
|
||||
On might counter that requiring a specific base class for a particular
|
||||
interface is unPythonic. However, in the specific case of exceptions
|
||||
there's a good reason (which has generally been agreed to on
|
||||
python-dev): requiring hierarchy helps code that wants to *catch*
|
||||
One might counter that requiring a specific base class for a
|
||||
particular interface is unPythonic. However, in the specific case of
|
||||
exceptions there's a good reason (which has generally been agreed to
|
||||
on python-dev): requiring hierarchy helps code that wants to *catch*
|
||||
exceptions by making it possible to catch *all* exceptions explicitly
|
||||
by writing ``except BaseException:`` instead of
|
||||
``except *:``. [#hierarchy-good]_
|
||||
|
@ -48,7 +48,8 @@ Requiring a Common Superclass
|
|||
=============================
|
||||
|
||||
This PEP proposes introducing a new exception named BaseException that
|
||||
is a new-style class and has a single attribute, ``message``::
|
||||
is a new-style class and has a single attribute, ``message`` (that
|
||||
will cause the deprecation of the existing ``args`` attribute)::
|
||||
|
||||
class BaseException(object):
|
||||
|
||||
|
@ -65,9 +66,7 @@ is a new-style class and has a single attribute, ``message``::
|
|||
def __init__(self, message='', *args):
|
||||
"""Set 'message' and 'args' attribute"""
|
||||
self.message = message
|
||||
self.args = (message,)
|
||||
if args:
|
||||
self.args += args
|
||||
self.args = (message,) + args
|
||||
|
||||
def __str__(self):
|
||||
"""Return the str of 'message'"""
|
||||
|
@ -97,10 +96,7 @@ is a new-style class and has a single attribute, ``message``::
|
|||
deprecated.
|
||||
|
||||
"""
|
||||
if index == 0:
|
||||
return self.message
|
||||
else:
|
||||
return self.args[index-1]
|
||||
return self.args[index]
|
||||
|
||||
|
||||
The ``message`` attribute will contain either the argument passed in
|
||||
|
@ -114,13 +110,13 @@ No restriction is placed upon what may be passed in for ``messsage``.
|
|||
This provides backwards-compatibility with how the argument passed
|
||||
into Exception has no restrictions.
|
||||
|
||||
The ``args`` attribute is to be deprecated. While allowing multiple
|
||||
The ``args`` attribute is deprecated. While allowing multiple
|
||||
arguments to be passed can be helpful, it is in no way essential. It
|
||||
also does not make it necessarily clear which argument is going to be
|
||||
represented by the ``__str__`` method. Restricting to a single
|
||||
argument keeps the API simple and clear. This also means providing a
|
||||
``__getitem__`` method is unneeded for exceptions and thus will be
|
||||
deprecated as well.
|
||||
also does not make it clear which argument is going to be represented
|
||||
by the ``__str__`` method. Restricting initialization to accepting a
|
||||
single argument keeps the API simple and clear. This also means
|
||||
providing a ``__getitem__`` method is unneeded for exceptions and thus
|
||||
will be deprecated as well.
|
||||
|
||||
The ``raise`` statement will be changed to require that any object
|
||||
passed to it must inherit from BaseException. This will make sure
|
||||
|
@ -141,11 +137,27 @@ With the exception hierarchy now even more important since it has a
|
|||
basic root, a change to the existing hierarchy is called for. As it
|
||||
stands now, if one wants to catch all exceptions that signal an error
|
||||
*and* do not mean the interpreter should be allowed to exit, you must
|
||||
specify all but two exceptions specifically in an ``except`` clause.
|
||||
specify all but two exceptions specifically in an ``except`` clause
|
||||
or catch the two exceptions separately and then re-raise them and
|
||||
have all other exceptions fall through to a bare ``except`` clause::
|
||||
|
||||
except (KeyboardInterrupt, SystemExit):
|
||||
raise
|
||||
except:
|
||||
...
|
||||
|
||||
That is needlessly explicit. This PEP proposes moving
|
||||
KeyboardInterrupt and SystemExit to inherit directly from
|
||||
BaseException.
|
||||
|
||||
::
|
||||
|
||||
- BaseException
|
||||
|- KeyboardInterrupt
|
||||
|- SystemExit
|
||||
|- Exception
|
||||
|- (all other current built-in exceptions)
|
||||
|
||||
Doing this makes catching Exception more reasonable. It would catch
|
||||
only exceptions that signify errors. Exceptions that signal that the
|
||||
intepreter should exit will not be caught and thus be allowed to
|
||||
|
|
Loading…
Reference in New Issue