[Patches] [ python-Patches-693195 ] Add sys.exc_clear() to clear current exception
SourceForge.net
noreply@sourceforge.net
Fri, 28 Feb 2003 18:00:34 -0800
Patches item #693195, was opened at 2003-02-25 16:26
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693195&group_id=5470
Category: Core (C code)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Add sys.exc_clear() to clear current exception
Initial Comment:
There is no way to clear the "current" exception, which is
available via the sys.exc_info() function. There are a few
(obscure) easons why one would want to be able to do so,
and mainly due to the implementation details of how
exception information is stored.
Specifically, sys.exc_info() will return information
on the last
exception even outside of an 'except:' block that
caught the
exception. So an exception and all of the frame
objects on the
stack, and all local variables stored in those frames
are kept
alive in the last exception traceback until either 1)
another
exception is thrown, or 2) the stack returns to a frame
that is
handling another exception (thrown before the "current"
exception).
Thus, it is sometimes useful to be able to clear the
"current"
exception. e.g.:
1) Some error handling and logging handlers will report
on the current or last exception (as a hint about
what may
have gone wrong). Once that information is handled,
additional error handling or logging calls should
not report
it again.
2) Sometimes resources are not released when an exception
is raised until the next exception is raised.
This causes
problems for programs that rely on object
finalization to
release resources (like memory, locks, file
descriptors, etc.).
Such code is suboptimal, but it exists and there
are few
easy alternatives other than creating many
'finally:' clauses
(which can violate encapsulation and abstraction layer
boundries and is syntactically hairy at times).
Anyhow,
such programs may want to clear the current exception
and trigger garbage collection at certain
synchronization
points, in order to flush pending object
finalization. Clearly,
this is a somewhat hit-or-miss strategy, though it
works
fairly well on practice, though no sane developer
should
ever rely on it.
Anyhow, I've implemented a trivial patch to sysmodule.c
to add a 'exc_clear()' function that clears the current
or last exception. I've also added a test case and
updated the documentation.
----------------------------------------------------------------------
>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-02-28 21:00
Message:
Logged In: YES
user_id=6380
Grabbing this for review.
----------------------------------------------------------------------
Comment By: Kevin Jacobs (jacobs99)
Date: 2003-02-26 07:39
Message:
Logged In: YES
user_id=459565
I've updated my patchj based on Neil's feedback:
1) sys_exc_clear and sys_exc_info now use the
recommended prototype and the cast to
PyCFunction was removed.
2) \versionadded was added to the exc_clear docs.
3) The exc_info docs were slightly modified to better
match the updated doc string.
----------------------------------------------------------------------
Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-25 22:32
Message:
Logged In: YES
user_id=33168
I have a couple of minor things. The prototype should be:
sys_exc_clear(PyObject *self, PyObject *noargs). This will
remove the (PyCFunction) cast. (I realize there are other
places in the file you copied, but they are wrong too. :-)
The doc for exc_clear should have a \versionadded{2.3}
before the \end. Should the doc for exc_info() also be
updated, since the docstring was updated?
----------------------------------------------------------------------
Comment By: Kevin Jacobs (jacobs99)
Date: 2003-02-25 16:39
Message:
Logged In: YES
user_id=459565
Before someone else says it -- yes, technically there is a way
to "clear" the current exception -- by raising another
exception.
However that leaves a bogus excepton in the thread state, which
still stores at least one Python stack frame.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=693195&group_id=5470