Bug 13791 - Xamarin Studio is not detecting the actual exception type thrown from a bound library.
Summary: Xamarin Studio is not detecting the actual exception type thrown from a bound...
Status: RESOLVED DUPLICATE of bug 7459
Alias: None
Product: Android
Classification: Xamarin
Component: Mono runtime / AOT Compiler ()
Version: 4.8.x
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2013-08-06 18:50 UTC by David Hathaway
Modified: 2013-08-07 15:14 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Sample project to reproduce bug (263.60 KB, application/octet-stream)
2013-08-06 18:50 UTC, David Hathaway
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:
Status:
RESOLVED DUPLICATE of bug 7459

Description David Hathaway 2013-08-06 18:50:11 UTC
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);

			try
			{
				// A SecureStorageSDKException should be thrown when using an "unknown" key
				secureStorage.GetString ("unknown key");
			}
			catch(SecureStorageSDKException ex)
			{
				Toast.MakeText (this, "Catched expected exception: " + ex, ToastLength.Long).Show();
				System.Diagnostics.Debug.Assert (ex.ErrorCode == SecureStorageSDKErrorCodes.UnknownKey);
			}
			catch(Exception ex)
			{
				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.

http://screencast.com/t/Ipf9acVPs8

https://gist.github.com/dwhathaway/db9d599ff76205750528
Comment 1 Mikayla Hutchinson [MSFT] 2013-08-07 14:01:41 UTC
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.
Comment 2 Jeffrey Stedfast 2013-08-07 14:11:53 UTC
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.
Comment 3 Jeffrey Stedfast 2013-08-07 14:24:23 UTC
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
Comment 4 Atsushi Eno 2013-08-07 14:28:54 UTC
Of course binding generator cannot control which managed exception can be thrown.
Comment 5 Mikayla Hutchinson [MSFT] 2013-08-07 15:00:57 UTC
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.
Comment 6 Jonathan Pryor 2013-08-07 15:14:51 UTC
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 ***