On Mar 27, 2008, at 8:44 AM, Albert Strasheim wrote:
Hello
I recently had a situation where I wrote a callback that called
another function that threw a RuntimeException.
For the longest time I couldn't figure out why my JUnit test wasn't
failing. The reason is obvious now: JNA prints the exception to
stderr, since there isn't really anything else it can do with it.
However, it seems to me like this could lead to failures passing by
unnoticed. I think it would be useful if JNA could be configured
(maybe on a per-library basis) as to how it should deal with uncaught
exceptions, analogous to Thread's setUncaughtExceptionHandler and
setDefaultUncaughtExceptionHandler.
This way, I can log the exception using log4j and then exit the VM, or
maybe set a flag that my JUnit tests can check.
As you surmised, there's no way for JNA to know whether there's a VM
context on the stack that would be able to handle any uncaught
exception. Where there is for callbacks that are directly invoked
during a native invocation, some callbacks might be called on non-VM
threads.
There are several contexts on which to base an equivalent to
setUncaughtExceptionHandler/setDefaultUncaughtExceptionHandler.
global (same as setDefaultUncaughtExceptionHandler)
per-library
per-native function
per-callback
I suppose it's not that much more complex to provide for all of these
contexts; the handler is stored based on whatever context is given.
This would require the native callback handling code to call back into
the VM when an exception is encountered (I suppose the default could
print to System.err and exit, but that's not actually the same thing
as stderr).
2 messages in net.java.dev.jna.usersRe: [jna-users] Callbacks and exceptions
