Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 4559 [details]
Sample project to reproduce bug
The attached project binds a 3rd party library. The expected outcome of the sample app is that an exception of type SecureStorageSDKException is thrown, and should be caught in the first part of the try/catch statement.
var secureStorage = SecureStorageSDK.Init("mySecureStorage", "1234", 8, this);
// A SecureStorageSDKException should be thrown when using an "unknown" key
secureStorage.GetString ("unknown key");
Toast.MakeText (this, "Catched expected exception: " + ex, ToastLength.Long).Show();
System.Diagnostics.Debug.Assert (ex.ErrorCode == SecureStorageSDKErrorCodes.UnknownKey);
Console.Write (ex.ToString ());
Toast.MakeText (this, "Expected SecureStorageSDKException, but got " + ex, ToastLength.Long).Show();
In the following gist, I see the exception com.vasco.digipass.sdk.utils.securestorage.SecureStorageSDKException. However, the try/catch in the calling code isn't getting this exception information. Actually, Xamarin Studio is showing the value of the Exception to be (null) in this case. In this screencast, you'll see that I hit the first breakpoint before the library is initialized. The next breakpoint is in the second Catch statement, and XS shows the value of the Exception ex as null. However, the Console.Write(ex.ToString()); call is actually outputting the correct stack trace information.
The type of the exception is Java.Lang.Exception, not SecureStorageSDKException. So that's a bug in the binding or the binding generator.
The "ex" local appearing to be null is a debugger issue.
The 'ex' variable showing null is because of a variable scoping bug (the compiler's debug metadata doesn't have correct scoping information).
You can work around this issue by renaming one of the 'ex' variables to something else.
Actually... instead of playing hot potato for the multiple buglets in this report, let me file a new bug for the compiler scope issue and assign this to the Android team to figure out the binding issue.
I've submitted a new bug report (for a bug that Alan, Zoltan, Marek and myself have been discussing in email after discovering it a week or so ago). It is filed as bug #13828
Of course binding generator cannot control which managed exception can be thrown.
Why not? Presumably at the point the Java exception is caught and wrapped in a C# exception, there could be a way to use different C# wrapper exception types depending on the Java exception type.
Dupe of Bug #7459; in particular, see: https://bugzilla.xamarin.com/show_bug.cgi?id=7459#c3
The issue is that in attempting to be a "low overhead" binding (e.g. no expensive Reflection-based lookups at app startup or Assembly load), when creating a MCW (C# wrapper) over a Java instance we may choose a more "generic" type than is desirable.
This should probably be documented... :-/
*** This bug has been marked as a duplicate of bug 7459 ***