Marshalled managed exceptions should be considered unhandled exceptions by the debugger

[rolfbjarne]

The debugger should consider (at least by default) marshalled managed exceptions as unhandled exceptions, and break.

This has become more important with .NET, where we've enabled exception marshalling by default.

A managed exception may now do the following:

• For iOS and tvOS: get converted into an Objective-C exception, which may end up aborting the process (without the debugger breaking).
• For Mac Catalyst and macOS: get converted into an Objective-C exception, which AppKit swallows and goes on its merry way (without the debugger breaking).

Neither are good scenarios, so we should look into what needs to happen to make the debugger break when an exception is marshalled (it's possible runtime changes will be needed).

Ref: dotnet/maui#7176

[rolfbjarne]

I wonder if we can just call mono_debugger_agent_unhandled_exception like Android does:

https://github.com/xamarin/xamarin-android/blob/1d24421106f5a07b7c150c4390e7d722fe4e618d/src/native/monodroid/monodroid-glue.cc#L837

[StephaneDelcroix]

hitting the same issue when executing invalid IL. no exception reported, but a crash logged in Console.app

[rolfbjarne]

Calling mono_debugger_agent_unhandled_exception helps, now exceptions in event handlers in Mac Catalyst aren't just silently ignored:

However, it seems the app stops too late to show the correct location, the stack has already been unwound a bit (native stacktrace). I believe this is because the debugger and/or runtime doesn't consider that exceptions that happen as a result of calling mono_runtime_invoke aren't handled.

@thaystg is this something you can give advice about? It seems that doing something like this:

static void DoSomething () { throw new Exception ("exception!"); }

MonoMethod *doSomethingMethod = ...;
void *arg_ptrs [1];
MonoObject *exception = NULL;
MonoObject *ret;

ret = mono_runtime_invoke (doSomethingMethod, NULL, arg_ptrs, &exception);

won't make the debugger in VSCode stop when the exception is thrown.

[rolfbjarne]

Seems like this is a variation of dotnet/android#4927 (comment)

[jonpryor]

@rolfbjarne: I suspect what you want/need is Debugger.BreakForUserUnhandledException(Exception), added in .NET 9.

See also:

• https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.debuggerdisableuserunhandledexceptionsattribute?view=net-9.0
• https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.debugger.breakforuserunhandledexception?view=net-9.0#system-diagnostics-debugger-breakforuserunhandledexception(system-exception)
• Remove JNINativeWrapper.CreateDelegate() Usage From Marshal Methods dotnet/java-interop#1258

[jonpryor]

Note: Debugger.BreakForUserUnhandledException() only works when using the "ICorDebug" debugger backend, not mono/debugger-libs.

[rolfbjarne]

@jonpryor I don't think that API will get us (nor you in fact) the behavior we want.

We want the debugger to break when the exception is thrown:

• if it's not handled,
• or only handled in our managed<->native/java trampolines.

That attribute will prevent the debugger from breaking when the exception is thrown, and then we call some API later on to let the debugger know "oh, sorry, please treat this exception as unhandled after all". However, at that point, the stack has already been unwound (somewhat at least), which means the debugging experience is subpar.

The documentation for DebuggerDisableUserUnhandledExceptionsAttribute says:

"the debugger won't break on user-unhandled exceptions when the exception is caught by a method with this attribute" - we want the opposite of this, something like: "the debugger will break on user-unhandled exceptions even if the exception is caught by a method with this attribute" (or more accurately "the debugger will not consider any exception handlers in this method when determining whether an exception is handled or not")

Additionally, we don't have any managed method to attach any attributes or run custom code in, because use the embedding API - mono_runtime_invoke - so we'd need a solution that works for that as well.