Restore changeset 5bd9db528aed (issue #18408)

"Issue #18408: PyObject_Str(), PyObject_Repr() and type_call() now fail with an
assertion error if they are called with an exception set (PyErr_Occurred()).

As PyEval_EvalFrameEx(), they may clear the current exception and so the caller
looses its exception."
This commit is contained in:
Victor Stinner 2013-08-26 14:05:19 +02:00
parent c82bfd871f
commit 33824f6fd7
2 changed files with 22 additions and 0 deletions

View File

@ -449,6 +449,14 @@ PyObject_Repr(PyObject *v)
if (Py_TYPE(v)->tp_repr == NULL)
return PyUnicode_FromFormat("<%s object at %p>",
v->ob_type->tp_name, v);
#ifdef Py_DEBUG
/* PyObject_Repr() must not be called with an exception set,
because it may clear it (directly or indirectly) and so the
caller looses its exception */
assert(!PyErr_Occurred());
#endif
res = (*v->ob_type->tp_repr)(v);
if (res == NULL)
return NULL;
@ -491,6 +499,13 @@ PyObject_Str(PyObject *v)
if (Py_TYPE(v)->tp_str == NULL)
return PyObject_Repr(v);
#ifdef Py_DEBUG
/* PyObject_Str() must not be called with an exception set,
because it may clear it (directly or indirectly) and so the
caller looses its exception */
assert(!PyErr_Occurred());
#endif
/* It is possible for a type to have a tp_str representation that loops
infinitely. */
if (Py_EnterRecursiveCall(" while getting the str of an object"))

View File

@ -736,6 +736,13 @@ type_call(PyTypeObject *type, PyObject *args, PyObject *kwds)
return NULL;
}
#ifdef Py_DEBUG
/* type_call() must not be called with an exception set,
because it may clear it (directly or indirectly) and so the
caller looses its exception */
assert(!PyErr_Occurred());
#endif
obj = type->tp_new(type, args, kwds);
if (obj != NULL) {
/* Ugly exception: when the call was type(something),