[Python-checkins] python/nondist/peps pep-0344.txt,1.3,1.4
ping@users.sourceforge.net
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
Modified Files:
pep-0344.txt
Log Message:
Update Rationale.
Index: pep-0344.txt
===================================================================
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 [8].
+
+ 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 [9]. 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 @@
C API
- 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* [8].
-
- 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.
Open Issues
- Walter Dörwald [9] expressed a desire to attach extra information
- to an exception during its upward propagation, without changing its
+ Walter Dörwald [10] 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
exceptions.
- It is not clear whether the '__context__' feature proposed here would
- be sufficient to cover all the use cases that Raymond Hettinger [1]
- 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 [1] 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 @@
[8] Guido van Rossum discusses automatic chaining in PyErr_Set*
http://mail.python.org/pipermail/python-dev/2003-June/036180.html
- [9] Walter Dörwald suggests wrapping exceptions to add details
+ [9] MSDN .NET Framework Library, "Exception.InnerException Property"
+ http://msdn.microsoft.com/library/en-us/cpref/html/frlrfsystemexceptionclassinnerexceptiontopic.asp
+
+ [10] Walter Dörwald suggests wrapping exceptions to add details
http://mail.python.org/pipermail/python-dev/2003-June/036148.html
More information about the Python-checkins
mailing list