I am using JNA in my project and my Java JNA Callbacks throw exception in some cases. I want to know from C/C++ code an exception was thrown by last calbback method call. In JNI, one can do it using env->ExceptionCheck() but could not find any equivalent in JNA.
Is there any possibility to achieve this?
The native code calling your callback certainly has no expectation that a Java exception will be raised. There is no guarantee that a JNA callback will be invoked from a containing JVM context. Even if it were, you'd have to establish an out of band channel to pass the exception from the callback to the JVM further up the stack, since you have no guarantees about the calling C code.
Assuming you have Java code -> C code -> callback, I'd recommend you catch all your callback's exceptions, then put them somewhere for the calling Java code to examine after the call.
You could make this happen under the covers with an InvocationMapper, which basically lets you capture and/or modify the results of an interface-mapped call, but it's probably easier just to be explicit about it and wrap the whole thing in a utility function.
For example:
public interface MyLibrary extends Library {
MyLibrary INSTANCE = (MyLibrary)Native.loadLibrary();
interface MyCallback extends Callback {
void invoke();
}
void myFunction(MyCallback callback);
}
Then you provide a utility wrapper:
public void myFunction(final MyCallback callback) {
final List<Exception> exceptions = new List<Exception>();
MyLibrary.INSTANCE.myFunction(new MyCallback() {
public void invoke() {
try {
callback.invoke();
} catch(Exception e) {
exceptions.add(e);
}
}
});
if (exceptions.size() > 0) {
// ...
}
}
Related
I have a native Android Activity that receives a callback interface as part of the Intent used to start it:
public interface ICallback : Serializable
{
void invoke(Result result);
}
I want to implement the callback in Xamarin as a lambda:
class CallbackWrapper : Java.Lang.Object, ICallback
{
private Action<Result> onInvoke;
public CallbackWrapper(Action<Result> onInvoke)
{
this.onInvoke = onInvoke;
}
public void Invoke(Result result)
{
this.onInvoke(result);
}
}
...
intent.PutExtra(CALLBACK_EXTRA, new CallbackWrapper(result => { ... }));
StartActivityForResult(intent);
The first problem is that when my callback gets deserialized from the intent bundle, I get the following exceptions:
System.NotSupportedException
Unable to activate instance of type CallbackWrapper from native handle 0xff...
System.MissingMethodException
No constructor found for CallbackWrapper::.ctor(System.IntPtr, Android.Runtime.JniHandleOwnership)
I add the constructor as explained in the exception:
class CallbackWrapper : Java.Lang.Object, ICallback
{
public CallbackWrapper(IntPtr handle, JniHandleOwnership transfer) : base(handle, transfer)
{
}
...
}
The exception is fixed, but now when the activity calls my handler, the onInvoke field is null. How do I get a reference to the onInvoke delegate that was used to create the Intent?
The solution - serialize a handle to the original object.
The first step is to enable object serialization. Serialization in Java is done using specially-named private methods, instead of through interface methods. Xamarin allows you to inject these methods into the generated Android callable wrappers using the Java.Interop.ExportAttribute attribute:
using Java.Interop;
class CallbackWrapper : Java.Lang.Object, ICallback
{
...
[Export("readObject", Throws = new[] { typeof(Java.IO.IOException), typeof(Java.Lang.ClassNotFoundException) })]
private void ReadObject(Java.IO.ObjectInputStream source)
{
}
[Export("writeObject", Throws = new[] { typeof(Java.IO.IOException), typeof(Java.Lang.ClassNotFoundException) })]
private void WriteObject(Java.IO.ObjectOutputStream destination)
{
}
}
Even if an ACW implements Serializable, the ACW itself has no useful fields - that why you need to serialize the managed state through the readObject/writeObject method pair.
Note that for this to work, your project needs to reference the Mono.Android.Export assembly, otherwise you'll get a build-time error.
The second part is getting a serializable reference to CallbackWrapper. This can be achieved using System.Runtime.InteropServices.GCHandle. The first step is to create a handle to the object and write it during serialization:
[Export("writeObject", Throws = new[] { typeof(Java.IO.IOException), typeof(Java.Lang.ClassNotFoundException) })]
private void WriteObject(Java.IO.ObjectOutputStream destination)
{
var handle = GCHandle.Alloc(this);
destination.WriteLong(GCHandle.ToIntPtr(handle).ToInt64());
}
The second step is deserialization:
[Export("readObject", Throws = new[] { typeof(Java.IO.IOException), typeof(Java.Lang.ClassNotFoundException) })]
private void ReadObject(Java.IO.ObjectInputStream source)
{
// deserialize GCHandle from stream
var handle = GCHandle.FromIntPtr(new IntPtr(source.ReadLong()));
// convert handle to object
var trueSelf = handle.Target as NativeValidationHandler;
// copy fields from original callback
this.onInvoke = trueSelf.onInvoke;
// free this handle
handle.Free();
}
The handle doesn't need to be a pinned handle, because we don't ever access the object's address, we just use the handle.
Note that in the above implementation you can only deserialize a callback once, because deserialization will free the handle. Alternatively you can allocate the handle once in the constructor and provide a Dispose method that frees that handle, if you wish to be able to deserialize the handle multiple times. Freeing the handle during deserialization also means that the object will never be collected if it's never deserialized, because the handle will prevent the object from being collected.
If you want to use Serializable than you are right. but i would recommend you to use Parcelable, because
Parcelable is a part of Android sdk and it's mainly made for parcelling purpose.
Parcelable is faster than Serializable because it doesn't use reflection while later does.
Although there is demerit that it has some boilerplate code.
Worth to read => https://android.jlelse.eu/parcelable-vs-serializable-6a2556d51538
I am new to Dart programming. I am trying to figure out what is the proper way (what everyone will do) to handle/guard those functions which are login required. The following is my first trial:
$ vim login_sample.dart:
var isLoggedIn;
class LoginRequiredException implements Exception {
String cause;
LoginRequiredException(this.cause);
}
Function loginRequired(Function f) {
if (!isLoggedIn) {
throw new LoginRequiredException("Login is reuiqred.");
}
return f;
}
void secretPrint() {
print("This is a secret");
}
void main(List<String> args) {
if (args.length != 1) return null;
isLoggedIn = (args[0] == '1') ? true : false;
try {
loginRequired(secretPrint)();
} on LoginRequiredException {
print("Login is required!");
}
}
then, run it with $ dart login_sample.dart 1 and $ dart login_sample.dart 2.
I am wondering if this is the recommended way to guard login required functions or not.
Thank you very much for your help.
Edited:
My question is more about general programming skills in Dart than how to use a plugin. In python, I just need to add #login_required decorator in the front of the function to protect it. I am wondering if this decorator function way is recommended in dart or not.
PS: All firebase/google/twitter/facebook etc... are blocked in my country.
I like the functional approach. I'd only avoid using globals, you can wrap it in a Context so you can mock then for tests and use Futures as Monads: https://dartpad.dartlang.org/ac24a5659b893e8614f3c29a8006a6cc
Passing the function is not buying much value. In a typical larger Dart project using a framework there will be some way to guard at a higher level than a function - such as an entire page or component/widget.
If you do want to guard at a per-function level you first need to decide with it should be the function or the call site that decides what needs to be guarded. In your example it is the call site making the decision. After that decision you can implement a throwIfNotAuthenticated and add a call at either the definition or call site.
void throwIfNotAuthenticated() {
if (!userIsAuthenticated) {
throw new LoginRequiredException();
}
}
// Function decides authentication is required:
void secretPrint() {
throwIfNotAuthenticated();
print('This is a secret');
}
// Call site decides authentication is required:
void main() {
// do stuff...
throwIfNotAuthenticated();
anotherSecreteMethod();
}
If I call the following RoboVM method with any non-null argument:
public static void runOnUiThread(final Runnable runnable) {
System.out.println("Inside runOnUiThread():");
System.out.println(" Null-check: "+(runnable==null));
NSOperation operation = new NSOperation() {
#Override
public void main() {
System.out.println("Inside main():");
System.out.println(" Null-check: "+(runnable==null));
runnable.run(); // NullPointerException here?!? How???
System.out.println(" main() completed");
}
};
NSOperationQueue.getMainQueue().addOperation(operation);
}
it outputs:
Inside runOnUiThread():
Null-check: false
Inside main():
Null-check: true
java.lang.NullPointerException
at RoboVMTools$1.main(RoboVMTools.java)
at org.robovm.apple.foundation.NSOperation.$cb$main(NSOperation.java)
at org.robovm.apple.uikit.UIApplication.main(Native Method)
at org.robovm.apple.uikit.UIApplication.main(UIApplication.java)
at Main.main(Main.java)
What on earth is going on??? And more importantly, how can I work around it?
I tried adding operation.addStrongRef(runnable); right before NSOperationQueue.... No difference.
I also tried moving the anonymous inner class into its own class that has a private final field to store the runnable which is passed into its constructor. Same result.
Am I just missing something totally obvious???
You are right about the GC. Your NSOperation instance is garbage collected before the operation is invoked from the Objective-C side. When NSOperationQueue calls into the Java side a new instance of your NSOperation anonymous class will be created which doesn't have a reference to the Runnable instance but rather null and the result is a NullPointerException getting thrown.
The way you resolved it using addStrongRef() is correct though only the mainQueue.addStrongRef(operation) and the corresponding removeStrongRef() calls should be sufficient:
public static void runOnUiThread(final Runnable runnable) {
final NSOperationQueue mainQueue = NSOperationQueue.getMainQueue();
NSOperation operation = new NSOperation() {
#Override
public void main() {
runnable.run();
mainQueue.removeStrongRef(this);
}
};
mainQueue.addStrongRef(operation);
mainQueue.addOperation(operation);
}
This will prevent the Java operation instance (and any Java objects reachable from it like the Runnable) from being GCed until the Objective-C NSOperationQueue instance is deallocated. As the Objective-C side queue is a singleton it won't get deallocated during the lifetime of the app.
The RoboVM NSOperationQueue Java class provides a version of the addOperation() method that takes a Runnable. When using this method RoboVM will take care of retaining the Runnable instance while it's needed by the Objective-C side for you. The same is true for any method that takes a #Block annotated parameter of type Runnable or any of the org.robovm.objc.block.VoidBlock* or org.robovm.objc.block.Block* interfaces.
Using this addOperation() method your code simply becomes:
public static void runOnUiThread(Runnable runnable) {
NSOperationQueue.getMainQueue().addOperation(runnable);
}
PS. The GC used by RoboVM has nothing to do with the Apple garbage collector so Apple's docs won't help you understand problems like this.
Well... This fixes it:
public static void runOnUiThread(final Runnable runnable) {
final NSOperationQueue mainQueue = NSOperationQueue.getMainQueue();
NSOperation operation = new NSOperation() {
#Override
public void main() {
runnable.run();
mainQueue.removeStrongRef(runnable);
mainQueue.removeStrongRef(this );
}
};
mainQueue.addStrongRef(runnable );
mainQueue.addStrongRef(operation);
mainQueue.addOperation(operation);
}
But don't ask my why this is necessary. The Apple docs say "In garbage-collected applications, the queue strongly references the operation object." So, operation.addStrongRef(runnable); as I tried earlier should have been sufficient as the operation object should be referenced by the queue anyways. But I guess the world doesn't always work the way I interpret the documentation.
This line in TopLevelTransaction (neo4j-kernel-2.1.2) throws a NullPointerException every time I call next() on an iterator obtained via GraphRepository#findAll():
protected void markAsRollbackOnly()
{
try
{
transactionManager.getTransaction().setRollbackOnly(); // NPE here
}
catch ( Exception e )
{
throw new TransactionFailureException(
"Failed to mark transaction as rollback only.", e );
}
}
I found some threads about similar crashes with slightly different stack traces. The accepted solution on this question is to use "proxy" transaction management, but that seems like a band-aid solution. This question also mentions "proxy" transaction management and suggests that there might be something wrong with the #Transactional annotation when using AspectJ.
Is this legitimately a bug, or have I just set up my project incorrectly? My code is essentially the same as in my standalone hello world, with a slightly more complex main class:
#Component
public class Test2 {
#Autowired
FooRepository repo;
public static void main(String[] args) {
AbstractApplicationContext context = new AnnotationConfigApplicationContext("test2");
Test2 test2 = context.getBean(Test2.class);
test2.doStuff();
}
public void doStuff() {
createFoo();
printFoos();
}
#Transactional
public Foo createFoo() {
Foo foo = new Foo();
foo.setName("Derp" + System.currentTimeMillis());
repo.save(foo);
System.out.println("saved " + foo.toString());
return foo;
}
#Transactional
public void printFoos() {
Iterable<Foo> foos = repo.findAll();
System.out.println("findAll() returned instance of " + foos.getClass().getName());
Iterator<Foo> iter = foos.iterator();
System.out.println("iterator is instance of " + iter.getClass().getName());
if(iter.hasNext()) {
iter.next(); // CRASHES HERE
}
}
}
I can post my POM if needed.
I didn't find a bug. Two or three things are required to make this work, depending on whether you want to use proxy or AspectJ transaction management.
First, transaction management must be enabled. Since I'm using annotation-based configuration, I did this by annotating my #Configuration class with #EnableTransactionManagement. Contrary to the docs, the default mode now seems to be AdviceMode.ASPECTJ, not AdviceMode.PROXY.
Next, you need to ensure that the Iterator is used within a transaction. In my example, if I use AdviceMode.PROXY the entire bean containing the #Autowired repository has to be annotated #Transactional. If I use AdviceMode.ASPECTJ I can annotate just the method. This is because the call to the method using the iterator is a self-call from within the bean, and proxy transaction management cannot intercept and manage internal calls.
Finally, if you're using AdviceMode.ASPECTJ you must set up weaving as discussed here.
I'm trying to really get Futures in Dart and I've noticed that just about every example I come across uses handleException to deal with exceptions that complete the Future. Yet the API documentation states "In most cases it should not be necessary to call handleException, because the exception associated with this Future will propagate naturally if the future's value is being consumed. Only call handleException if you need to do some special local exception handling related to this particular Future's value."
So when would I need "special local exception handling"? Could someone explain that in a bit more detail? Is there some code that I honestly can't run easily by letting the exception propagate?
Mads Ager gave me this answer:
Basically, this is the equivalent of having a try-catch in straight-line code:
int doSomethingElse() {
try {
return thisMightFail();
} catch(e) {
return -1;
}
}
void doSomething() {
int value = doSomethingElse();
// operate on value
}
With Futures it is something like this (not tested):
Future<int> doSomethingElse() {
return thisMightFail().transformException((e) => -1);
}
void doSomething() {
doSomethingElse().then((value) {
// operate on value
});
}
So this is for local exception handling instead of global exception handling. If you never use handleException or transformException that would correspond to always dealing with exceptions at the top level in non-async code.