Title: PyErr_Clear() vs. AsynchronousException
Type: Stage:
Components: Interpreter Core Versions:
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mwh Nosy List: arigo, christian.heimes, mwh
Priority: normal Keywords: patch

Created on 2004-08-16 11:23 by arigo, last changed 2008-01-04 19:54 by christian.heimes. This issue is now closed.

File name Uploaded Description Edit
pyerr_clear.diff arigo, 2004-08-16 11:23 PyErr_Clear() -> asynchronous exception
Messages (2)
msg46720 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2004-08-16 11:23
The core uses PyErr_Clear() in quite a number of places, which is bad.  It can hide a genuine problem like a MemoryError or an infinite recursion.  Fixing all these places is very difficult: there are a lot of functions that pretend they can't fail.  Instead, the current patch extends the asynchronous thread exception mecanism recently introduced, and PyErr_Clear() sends such an asynchronous exception to the current thread if it detects an exception that should not be lost.

"Should not be lost" is defined as subclassing from the new AsyncronousException class.  The exception hierarchy now looks like:

+-- SystemExit
+-- StopIteration
+-- StandardError
|   +-- almost_all_the_XxxError
+-- AsynchronousException
|   +-- KeyboardInterrupt
|   +-- RuntimeError
|   +-- MemoryError
+-- Warning

Some more thinking about it would be welcome.  Maybe AsynchronousException and a few others should not subclass Exception at all, so that "except Exception" statements don't catch them.  Anyway, this patch alreaddy improves the situation, because you can catch and re-raise AsynchronousException (instead of, say, just KeyboardInterrupt).

Incompatibility note: in CVS, NotImplementedError is a subclass of RuntimeError.  With this patch it doesn't make sense any more, so NotImplementedError now inherits directly from StandardError.

Finally note that the patch is a first draft, not really tested and documented (though it's already nice to be able to Ctrl-C out of a long-running hasattr() call).  In particular I'm not entierely sure when the asynchronous exception will be re-raised (though it should always be shortly after the original faulty opcode).  I'm not sure the tracebacks coming from such exceptions will always be correct (e.g. they could point to a point after the one that triggered the exception, or even skip a few recursion levels entierely).

Assigning to mwh because he seems interested in the idea.
msg59255 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-04 19:54
The problem was solved with the new BaseException class
Date User Action Args
2008-01-04 19:54:42christian.heimessetstatus: open -> closed
resolution: fixed
messages: + msg59255
nosy: + christian.heimes
2004-08-16 11:23:45arigocreate