[Python-checkins] python/nondist/peps pep-0344.txt,1.3,1.4
ping at users.sourceforge.net
Mon May 16 01:53:58 CEST 2005
Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2622
RCS file: /cvsroot/python/python/nondist/peps/pep-0344.txt,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -d -r1.3 -r1.4
--- pep-0344.txt 15 May 2005 23:29:56 -0000 1.3
+++ pep-0344.txt 15 May 2005 23:53:56 -0000 1.4
@@ -102,22 +102,29 @@
of tracebacks (from oldest to most recent frame) and because the
actual thrown exception is easier to find on the last line.
- Java and Ruby both discard the current exception when an exception
- occurs in a 'catch'/'rescue' or 'finally'/'ensure' clause. Perl 5
- lacks built-in structured exception handling. For Perl 6, RFC 88
- proposes an exception mechanism that retains all the chained
- exceptions in an array named @@. In that RFC, the most recently
- raised exception is exposed for matching, as in this PEP; also,
- arbitrary expressions (possibly involving @@) can be evaluated for
- exception matching.
+ To keep things simpler, the C API calls for setting an exception
+ will not automatically set the exception's '__context__'. Guido
+ van Rossum has has expressed concerns with making such changes .
+ As for other languages, Java and Ruby both discard the original
+ exception when another exception occurs in a 'catch'/'rescue' or
+ 'finally'/'ensure' clause. Perl 5 lacks built-in structured
+ exception handling. For Perl 6, RFC 88 proposes an exception
+ mechanism that retains chained exceptions in an array named @@.
+ In that RFC, the most recently raised exception is exposed for
+ matching, as in this PEP; also, arbitrary expressions (possibly
+ involving @@) can be evaluated for exception matching.
Exceptions in C# contain a read-only 'InnerException' property that
- may point to another exception. This property is not set by the VM
- automatically. Instead, the constructors of exception objects all
- accept an optional 'innerException' argument to explicitly set this
- property. The C# documentation says "an exception that is thrown as
- a direct result of a previous exception should include a reference
- to the previous exception in the InnerException property."
+ may point to another exception . According to its documentation,
+ "When an exception X is thrown as a direct result of a previous
+ exception Y, the InnerException property of X should contain a
+ reference to Y." This property is not set by the VM automatically;
+ rather, all exception constructors take an optional 'innerException'
+ argument to set it explicitly. The '__cause__' attribute fulfills
+ the same purpose as InnerException, but this PEP proposes adding a
+ single method to the base Exception class rather than extending the
+ constructors of all exceptions.
The reason all three of these attributes are presented together in
one proposal is that the '__traceback__' attribute provides
@@ -202,7 +209,11 @@
The '__cause__' attribute on exception objects is always initialized
to None. It is set by calling the 'setcause' method, a new method
defined on the base Exception class. For convenience, this method
- returns the exception itself.
+ returns the exception itself:
+ def setcause(self, cause):
+ self.__cause__ = cause
+ return self
In the following example, a database provides implementations for a
few different kinds of storage, with file storage as one kind. The
@@ -301,12 +312,10 @@
- To keep things simpler, the PyErr_Set* calls for setting exceptions
- will not set the '__context__' attribute on exceptions. The BDFL has
- has expressed qualms with making such changes to PyErr_Set* .
- PyErr_NormalizeException will always set the 'traceback' attribute
- to its 'tb' argument and the '__context__' attribute to None.
+ The PyErr_Set* calls for setting exceptions will not set the
+ '__context__' attribute on exceptions. PyErr_NormalizeException
+ will always set the 'traceback' attribute to its 'tb' argument and
+ the '__context__' and '__cause__' attributes to None.
A new API function, PyErr_SetContext(context), will help C
programmers provide chained exception information. This function
@@ -319,25 +328,28 @@
Chained exceptions expose the type of the most recent exception, so
they will still match the same 'except' clauses as they do now.
- The proposed changes should not break any code except for code that
- currently sets or depends on the values of attributes named
- '__context__', '__cause__', or '__traceback__' on exception
- instances. As of 2005-05-12, the Python standard library contains
- no mention of such attributes.
+ The proposed changes should not break any code unless the code sets
+ or uses attributes named '__context__', '__cause__', 'setcause', or
+ '__traceback__' on exception instances. As of 2005-05-12, the
+ Python standard library contains no mention of such attributes.
- Walter Dörwald  expressed a desire to attach extra information
- to an exception during its upward propagation, without changing its
+ Walter Dörwald  expressed a desire to attach extra information
+ to an exception during its upward propagation without changing its
type. This could be a useful feature, but it is not addressed by
this PEP. It could conceivably be addressed by a separate PEP
establishing conventions for other informational attributes on
- It is not clear whether the '__context__' feature proposed here would
- be sufficient to cover all the use cases that Raymond Hettinger 
- originally had in mind.
+ It is not clear whether the '__context__' and '__cause__' features
+ proposed here would be sufficient to cover all the use cases that
+ Raymond Hettinger  originally had in mind.
+ As written, this PEP makes it impossible to suppress '__context__',
+ since setting exc.__context__ to None will only result in it being
+ set again the moment that exc is raised.
The exception context is lost when a 'yield' statement is executed;
resuming the frame after the 'yield' does not restore the context.
@@ -430,7 +442,10 @@
 Guido van Rossum discusses automatic chaining in PyErr_Set*
-  Walter Dörwald suggests wrapping exceptions to add details
+  MSDN .NET Framework Library, "Exception.InnerException Property"
+  Walter Dörwald suggests wrapping exceptions to add details
More information about the Python-checkins