iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Finish moving to BaseException/Exception naming. Also leave in StandardError 

so as to provide a base Error exception that inherits from Exception.  Also
allows Warning to inherit from Exception without being put at the same level as
any *Error exceptions.
This commit is contained in:
Brett Cannon 2005-08-04 03:33:03 +00:00
parent 322b187c06
commit 36271756e4
1 changed files with 66 additions and 69 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

135
pep-0348.txt
View File

@ -19,7 +19,7 @@ This PEP proposes doing a reorganization for Python 3.0 when backwards-compatibi
Along with this reorganization, adding a requirement that all objects passed to
a ``raise`` statement must inherit from a specific superclass is proposed.
Lastly, bare ``except`` clauses will catch only exceptions inheriting from
StandardError.
Exception.
Rationale
@ -43,7 +43,7 @@ Lastly, bare ``except`` clauses are to catch only exceptions that inherit from
Exception [python-dev3]_.
While currently used to catch all exceptions, that use is rather far reaching
and typically not desired.
Catching only exceptions inheriting from StandardError allows exceptions that
Catching only exceptions inheriting from Exception allows exceptions that
should not be caught unless explicitly desired to continue to propagate up the
execution stack.
@ -66,6 +66,8 @@ Lastly, any renaming to make an exception's use more obvious from its name was d
Having to look up what an exception is meant to be used for because the name does not proper reflect its usage is annoying and slows down debugging.
Having a proper name also makes debugging easier on new programmers.
But for simplicity of existing user's and for transitioning to Python 3.0, only exceptions whose names were fairly out of alignment with their stated purpose have been renamed.
It was also made sure the exceptions dealing with errors had the "Error"
suffix.
New Hierarchy
=============
@ -86,36 +88,37 @@ New Hierarchy
+-- StopIteration (broader inheritance)
+-- SystemExit (broader inheritance)
+-- Exception
+-- ArithmeticError
+-- DivideByZeroError
+-- FloatingPointError
+-- OverflowError
+-- AssertionError
+-- AttributeError
+-- EnvironmentError
+-- IOError
+-- EOFError (broader inheritance)
+-- OSError
+-- ImportError
+-- LookupError
+-- IndexError
+-- KeyError
+-- NamespaceError (rename of NameError)
+-- UnboundFreeError (new)
+-- UnboundGlobalError (new)
+-- UnboundLocalError
+-- NotImplementedError (stricter inheritance)
+-- SyntaxError
+-- IndentationError
+-- TabError
+-- TypeError
+-- UserError (rename of RuntimeError)
+-- UnicodeError
+-- UnicodeDecodeError
+-- UnicodeEncodeError
+-- UnicodeTranslateError
+-- ValueError
+-- Warning (broader inheritance, including subclasses)
+-- StandardError
+-- ArithmeticError
+-- DivideByZeroError
+-- FloatingPointError
+-- OverflowError
+-- AssertionError
+-- AttributeError
+-- EnvironmentError
+-- IOError
+-- EOFError (broader inheritance)
+-- OSError
+-- ImportError
+-- LookupError
+-- IndexError
+-- KeyError
+-- NamespaceError (rename of NameError)
+-- UnboundFreeError (new)
+-- UnboundGlobalError (new)
+-- UnboundLocalError
+-- NotImplementedError (stricter inheritance)
+-- SyntaxError
+-- IndentationError
+-- TabError
+-- TypeError
+-- UserError (rename of RuntimeError)
+-- UnicodeError
+-- UnicodeDecodeError
+-- UnicodeEncodeError
+-- UnicodeTranslateError
+-- ValueError
+-- Warning
+-- AnyDeprecationWarning (new; broader inheritance for subclasses)
+-- PendingDeprecationWarning
+-- DeprecationWarning
@ -144,6 +147,12 @@ inheritance was deemed incorrect and needed correction.
New Exceptions
--------------
BaseException
'''''''''''''
The superclass that all exceptions must inherit from.
CriticalError
'''''''''''''
@ -159,7 +168,7 @@ ControlFlowException
This exception exists as a superclass for all exceptions that directly deal
with control flow.
Inheriting from Exception instead of StandardError prevents them from being caught accidently when one wants to catch errors.
Inheriting from BaseException instead of Exception prevents them from being caught accidently when one wants to catch errors.
The name, by not mentioning "Error", does not lead to one to confuse the subclasses as errors.
@ -214,7 +223,7 @@ the exception as quick-and-dirty error exception for the user to use.
The name also keeps it in line with UserWarning.
If a user wants an exception that is not to be used as an error, raising
Exception directly should be sufficient as StandardError, as UserError inherits
BaseException directly should be sufficient as Exception, as UserError inherits
from, is only used for errors.
@ -255,11 +264,11 @@ Changed Inheritance
KeyboardInterrupt, MemoryError, and SystemError
'''''''''''''''''''''''''''''''''''''''''''''''
Inherit from CriticalError instead of StandardError.
Inherit from CriticalError instead of Exception.
The three above-mentioned exceptions are not standard errors by any means.
They are raised asynchronously by the interpreter when something specific has
occurred. Thus they warrant not inheriting from StandardError but from an
occurred. Thus they warrant not inheriting from Exception but from an
entirely separate exception that will not be caught by a bare ``except``
clause.
@ -267,11 +276,11 @@ clause.
NotImplementedError
'''''''''''''''''''
Inherits from StandardError instead of RuntimeError (renamed UserError).
Inherits from Exception instead of RuntimeError (renamed UserError).
Originally inheriting from RuntimeError, NotImplementedError does not have any
direct relation to the exception meant for use in user code as a
quick-and-dirty exception. Thus it now directly inherits from StandardError.
quick-and-dirty exception. Thus it now directly inherits from Exception.
EOFError
@ -282,15 +291,6 @@ Subclasses IOError.
Since an EOF comes from I/O it only makes sense that it be considered an I/O error.
Warning
'''''''
Inherits from StandardError instead of Exception.
In order for Warning to be caught by bare ``except`` clauses, it needs to
inherit from StandardError as specified in this PEP.
Required Superclass for ``raise``
=================================
@ -298,7 +298,7 @@ By requiring all objects passed to a ``raise`` statement inherit from a specific
If PEP 342 [PEP344]_ is accepted, the attributes outlined there will be guaranteed to be on all exceptions raised.
This should help facilitate debugging by making the querying of information from exceptions much easier.
The proposed hierarchy has Exception as the required class that one must inherit from.
The proposed hierarchy has BaseException as the required class that one must inherit from.
Implementation
@ -310,8 +310,8 @@ an exception should be enough. For the C API, all functions that set an
exception will have the same inheritance check.
Bare ``except`` Clauses Catching StandardError Only
===================================================
Bare ``except`` Clauses Catching Exception Only
===============================================
While Python does have its "explicit is better than implicit" tenant, it is not
necessary if a default behavior is reasonable. In the case of a bare
@ -322,15 +322,15 @@ In Python 2.4, a bare ``except`` clause will catch all exceptions. Typically,
though, this is not what is truly desired.
More often than not one wants to catch all error exceptions that do not signify
a bad state of the interpreter. In the new exception hierarchy this is
embodied by StandardError. Thus bare ``except`` clauses will catch only
exceptions inheriting from StandardError.
embodied by Exception. Thus bare ``except`` clauses will catch only
exceptions inheriting from Exception.
Implementation
--------------
In the compiler, when a bare ``except`` clause is reached, the code for
``except StandardError`` will be emitted.
``except Exception`` will be emitted.
Transition Plan
@ -414,17 +414,14 @@ exception at any point in code it has a more proper place inheriting from
CriticalException. It also keeps the name of the exception from being "CriticalError".
Renaming Exception to Raisable, StandardError to Exception
----------------------------------------------------------
Other Names for BaseException and Exception
-------------------------------------------
While the naming makes sense and emphasizes the required superclass as what
must be inherited from for raising an object, the naming is not required.
Keeping the existing names minimizes code change to use the new names.
It has been argued that changing StandardError to Exception might actually
reflect how users use Exception more accurately, that has not been considered a
strong enough argument. It entails guessing as to what users think in general
and does technically lead to a change that is not backwards-compatible.
Alternative names for BaseException/Exception have been Raisable/Exception and
Exception/StandardError. The former has been rejected on the basis that
Raisable does not reflect how it is an exception well enough. The latter was
rejected based on the fact that it did not reflect current use as the chosen
names do.
DeprecationWarning Inheriting From PendingDeprecationWarning
@ -472,12 +469,12 @@ Proposed because a SystemError is meant to lead to a system exit, the idea was
removed since CriticalException signifies this better.
ControlFlowException Under StandardError
----------------------------------------
ControlFlowException Under Exception
------------------------------------
It has been suggested that ControlFlowException inherit from StandardError.
It has been suggested that ControlFlowException inherit from Exception.
This idea has been rejected based on the thinking that control flow exceptions
are typically not desired to be caught in a generic fashion as StandardError
are typically not desired to be caught in a generic fashion as Exception
will usually be used.
@ -498,8 +495,8 @@ Remove ControlFlowException?
It has been suggested that ControlFlowException is not needed.
Since the desire to catch any control flow exception will be atypical, the
suggestion is to just remove the exception and let the exceptions that
inherited from it inherit directly from Exception. This still preserves the
seperation from StandardError which is one of the driving factors behind the
inherited from it inherit directly from BaseException. This still preserves the
seperation from Exception which is one of the driving factors behind the
introduction of the exception.