C API functions returns a special value unambiguously signaling about a raised exception (NULL or -1). But in some cases this is ambiguous, because the special value is a legitimate value (e.g. -1 for PyLong_AsLong() or NULL for PyDict_GetItem()). Needed to use PyErr_Occurred() to distinguish between successful and failed call. The problem is that if PyLong_AsLong() is called when the exception is set, successful call returned -1 is interpreted as failed. Since it is happen in very rare case, this bug is usually unnoticed. Attached experimental patch makes some functions like PyLong_AsLong() always failing if called with an exception set. Some tests are failed with it applied: test_compile test_datetime test_io test_os test_symtable test_syntax test_xml_etree_c.
Ah yes. Some months (years?) ago, i started to add assertions to fail if some functions are called with an exception set. Checking if an exception is set at runtime adds a low overhead. Maybe it's better to fail with a fatal error (like an assertion error) in debug mode (and do nothing in release mode). But I'm not sure that developers of C extensions are all able to get a Python compiled in debug mode :-/ That's also why I added a check a runtime: raise a SystemError if a function with an exception set. I also added PYTHONMALLOC=debug to make some debug checks easily available on release builds. The bug also reminds me my PEP 490 to chain exceptions. It would be yet another option... So well, I don't know what is the best option.
