Uncaught exception in PyObject getIntValue() showes up in the next PyListWrapper.size() call

[jmao-denver]

In Python,

def foo():
    return [[], None]

In Java, after calling foo() and let 'obj' receive the return value as PyObject

obj.get(1).getIntValue();
obj.get(0).asList().size()

would throw an exception

java.lang.RuntimeException: Error in Python interpreter:
Type: <class 'SystemError'>
Value: <method-wrapper '__len__' of list object at 0x158099dc0> returned a result with an exception set
Line: <not available>
Namespace: <not available>
File: <not available>
Traceback (most recent call last):

        at org.jpy.PyLib.callAndReturnObject(Native Method)
        at org.jpy.PyObject.callMethod(PyObject.java:432)
        at org.jpy.PyListWrapper.size(PyListWrapper.java:36)

[jmao-denver]

In org_jpy_PyLib.c

/*
 * Class:     org_jpy_python_PyLib
 * Method:    getIntValue
 * Signature: (J)I
 */
JNIEXPORT jint JNICALL Java_org_jpy_PyLib_getIntValue
  (JNIEnv* jenv, jclass jLibClass, jlong objId)
{
    PyObject* pyObject;
    jint value;

    JPy_BEGIN_GIL_STATE

    pyObject = (PyObject*) objId;
    value = (jint) JPy_AS_CLONG(pyObject);

    JPy_END_GIL_STATE

    return value;
}

This code doesn't bother to check for errors after the call to JPy_AS_CLONG() and there are a bunch of other methods behave the same. From a performance POV, if we insist that to void such issue, callers need to call the PyObject.isXXX() to check for the expected type first before calling the corresponding getXXX(), this would lead to one more Java/Python boundary crossing and worse performance than if the getXXX() would check for errors in the C function and raise the Java exception accordingly.