Can I use C++ exceptions in JNI library on Android?

Question

Is there any way that I can use C++ exceptions in a JNI (Java Native Interface) library on Android?

EDIT: I am talking about C++ exception handling that is entirely internal to the JNI library. That is, the exception is both thrown and catched within the library, and it never escapes the library.

According to the Android documentation (docs/CPLUSPLUS-SUPPORT.html), exceptions are only supported if I use 'GNU libstdc++' as the C++ runtime instead of the default.

The problem is that the documentation also states that all parts of a program must use the same C++ runtime:

"You can only select a single C++ runtime that all your code will depend on. It is not possible to mix shared libraries compiled against different C++ runtimes."

According to my interpretation, this means that I am forced to use the same C++ runtime as Dalvik (Java VM on Android).

So, if Dalvik does not use 'GNU libstdc++', is there still a way that I can use exceptions in my JNI lib?

What C++ runtime is Dalvik compiled against?

EDIT: I have to assume that whichever Java app is using my JNI library, may also want to use other JNI libraries, that I have no control over. Does that in any way limit my options?

Answer 1

Yes you can use exceptions with

APP_STL := gnustl_static

or gnustl_shared . The doc uses kindof intimidating language but they only want you not to mix libraries that expect different STL implementations in your app . That's why the setting has APP_ prefix, not LOCAL_ .

Dalvik VM fully supports any of the STL implementations listed in the doc.

Usually you control both sides of your JNI, and can make sure that all native components are compiled for gnustl_shared. This is the preferred scenario.

If your business is to provide a black box library that may be used by other people who could decide to also include other libraries, it's safer to choose gnustl_static to support C++ exceptions in your code. This way you don't depend on others' good will. You should be careful to design your API so that your native objects ( and especially exceptions ) never get exposed to other components.