PyErr_Clear() vs. AsynchronousException

[arigo]

BPO	1009929
Nosy	@mwhudson, @arigo, @tiran
Files	pyerr_clear.diff: PyErr_Clear() -> asynchronous exception

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/mwhudson'
closed_at = <Date 2008-01-04.19:54:42.810>
created_at = <Date 2004-08-16.11:23:45.000>
labels = ['interpreter-core']
title = 'PyErr_Clear() vs. AsynchronousException'
updated_at = <Date 2008-01-04.19:54:42.809>
user = 'https://github.com/arigo'

bugs.python.org fields:

activity = <Date 2008-01-04.19:54:42.809>
actor = 'christian.heimes'
assignee = 'mwh'
closed = True
closed_date = <Date 2008-01-04.19:54:42.810>
closer = 'christian.heimes'
components = ['Interpreter Core']
creation = <Date 2004-08-16.11:23:45.000>
creator = 'arigo'
dependencies = []
files = ['6190']
hgrepos = []
issue_num = 1009929
keywords = ['patch']
message_count = 2.0
messages = ['46720', '59255']
nosy_count = 3.0
nosy_names = ['mwh', 'arigo', 'christian.heimes']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1009929'
versions = []

[arigo]

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:

Exception
|
+-- 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.

[tiran]

The problem was solved with the new BaseException class