Java: How are errors customarily handled for native code in jni calls?

Question

I've google'd around a bit, and haven't really found a good answer for my question: What is the customary way to pass back error information to java from native jni code?

I would normally just pick a design and go with it, but this code is called every 5 milliseconds, (approx), so I thought I'd ask if there's a customary 'clean / efficient' way to do this.

The way I see it, I have four obvious options:

1. On each call, in java create an "error return" object and pass it through to the JNI. If there's a problem, the native code fills in the error description in this object, and the java code checks it on return. Since errors are not the common case, this creates a lot of objects for the GC to clean up, and 99.99% of them are unnecessary.

2. Similar to #1, create some single "error return" object in the java class which is passed to each method call over and over. Check it in the java code on each return for errors. This seems dodgy to me, but maybe it's the proper option?

3. Create an object in the native code which contains a description of the error if applicable, and pass it back as a return value to java. After the call in java, check the return for null. This seems less wasteful than #1, but it seems a bit awkward.

4. Simply build a integer return value on the jni method, and pass back an int corresponding to the "exit" value of the native code. Enumerate all possible native exit states in a java map. Compare the return value to '0', and look up the error in this map if necessary. This appears more efficient than the others, but seems more clumsy, since a change in native code would require someone to go back and update the "error table".

I feel as though I'm missing something obvious... is there a guru out there that can offer any insight?

Thanks!

Answer 1

Throw java exceptions: http://java.sun.com/docs/books/jni/html/exceptions.html?

Answer 2

Regarding the methods you noted:

1. As you mentioned, this generates a lot of allocation/deallocation calls which.
2. This method won't work if you have more than 1 thread calling your native code.
3. This assumes you don't need the return value for anything else. There's also the question of where and when your error object is 'freed'.
4. Assuming you're not using the return value for anything else and that you don't need any 'extra' information about the error, this is a good solution. The possible errors shouldn't change often enough that it would create a problem in updating the Java code.

Of course, if you do need your return value, and if you want more detailed information regarding the actual error, you should use exceptions.