[FR] add exception handling after JNI calls

Currently all JNI calls made unchecked. The checked call demo:

function test1(name)
  return android.jni:context(android.app.activity.vm, function(jni)
    local clz, e = jni.env[0].FindClass(jni.env, name), jni.env[0].ExceptionCheck(jni.env)
    if e == 0 then
      e = nil
    else
      local ex = jni.env[0].ExceptionOccurred(jni.env)
      jni.env[0].ExceptionClear(jni.env)
      e = jni:to_string(
        jni:callObjectMethod(ex, "getMessage", "()Ljava/lang/String;")
        )
    end
    return clz, e
  end)
end
local clzz, e = test1("java/lang/WRONGNAME")
if e then
  print(e)
end

[pazos]

jni.env[0].FindClass(jni.env, name) is a cool stuff if you’re implementing method invokation via reflection, because the name of the class in that case is not part of the API, and you’ll need to know if it is available on a given device. In that case makes sense to check exceptions before calling the method.

[pazos]

As the result I just annoy you with non-KR related ideas. Right? Then it’s time for me just to move away.

Not interested doesn’t mean annoyed. PRs are welcome for stuff that doesn’t relate to KOReader. But in this case is not a PR, but a feature request which doesn’t serve any purpose.

To call java from lua you’ll need to know:

1. the name of the class
2. the name of the method
3. the type of the method
4. method’s signature

Any typo or mismatch in any element would make your code crash. And because lua is dynamically typed luacheck won’t alert you as both “()Ljava/lang/String;” and “()Ljava/io/File;” are valid lua strings, but one is a valid signature for the method "getMessage" and the other is not.

The same happens when you’re checking exceptions: you call jni:callObjectMethod. If you call jni:callStaticObjectMethod you’ll trigger an error, because there isn’t any static method which returns an object named “getMessage” for the class ex.

Catching JNI exceptions isn’t a bad thing to add, but to serve a purpose it needs to thow the exception and interrupt the app flow, so the result would be exactly the same: a crash, but the way to retrieve the bug would be better as it would be associated to the app name and not a RuntimeError (mismatch signature) or a native crash (LuaJIT error dealing with libraries using FFI)