Support Global Exception Handling Mechanism for .NET MAUI

[TanayParikh]

Discussed in #653

^{Originally posted by AmSmart April 5, 2021}
With the new host model in .NET Maui, will we get a straightforward way of catching exceptions?

Currently this is possible in WPF/WinForms via:

AppDomain.CurrentDomain.UnhandledException += (sender, error) =>
{
    MessageBox.Show(text: error.ExceptionObject.ToString(), caption: "Error");
};

The ask of this issue is to enable AppDomain.CurrentDomain.UnhandledException for MAUI based applications to support a global exception handling mechanism.

I looked into the Windows MAUI WinUI3 end of things, and there appears to be a potential bug with the DispatcherQueue which prevents the application from being sent to the AppDomain.CurrentDomain.UnhandledException: microsoft/microsoft-ui-xaml#5221

cc/ @hartez @mattleibow

Blazor Hybrid

Cross linking dotnet/aspnetcore#40765 which handles the case of WPF/WinForms in Blazor Hybrid. If there's a canonical way to do global exception handling (like we have in WinForms/WPF), we need to ensure .NET MAUI Blazor Hybrid is able to integrate with it directly.

Blazor Hybrid MAUI tracking issue: #4441

• WPF/WinForms Blazor WebView Exception Handling aspnetcore#40765
• App.UnhandledException doesn't catch exceptions from other threads. microsoft/microsoft-ui-xaml#5221
• [Blazor webview] Exception handling for blazor webview #4441
• MAUI: enable AppDomain.CurrentDomain.UnhandledException for MAUI based applications to support a global exception handling mechanism

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ericgrantholland]

Any updates here? Will this be included in the .NET 8 release of MAUI?

This is a huge blocker for anyone using MAUI for real/prod applications. I'm using Blazor Hybrid and the app completely hangs when an error occurs with no way to inform the user of anything going on. I do see that AppDomain.CurrentDomain.FirstChanceException fires, but no other events get fired after that, at least to my knowledge.

A bit disappointing that this isn't considered high-priority considering MAUI is no longer in preview.

[Redth]

This idea of a global one size fits all mechanism is not as simple as it may first seem.

First of all there are several different runtime exception events that one may wish to subscribe to (or not) for potentially different reasons.

• AppDomain.CurrentDomain.UnhandledException
• AppDomain.CurrentDomain.FirstChanceException
• TaskScheduler.UnobservedTaskException

Then, there's some platform specific events as well:

• Microsoft.UI.Xaml.Application.Current.UnhandledException
• Android.Runtime.AndroidEnvironment.UnhandledExceptionRaiser
• ObjCRuntime.Runtime.MarshalManagedException

Finally, we haven't even mentioned native exceptions which would for example require something like PLCrashReporter on iOS to capture.

There may be some value in coming up with a better xplat API approach to helping with this problem, but it needs some time and thought to architect it.

For now it's certainly possible to wire these handlers up yourself by writing a few lines of platform specific code, in such a way that you get the results you're looking for (eg: do you want to handle unobserved task exceptions? maybe, but maybe not).

NOTE: reminder that there was a WinUI bug where capturing winui extensions did not always work due to this issue which might be conflated with this request. With that bug fixed in a recent release, it should at least be possible to handle the exceptions now

[ericgrantholland]

@Redth I have some more info about my use case for what it's worth.

It seems like errors thrown inside components are in fact caught by ErrorBoundaries (which is great). What made me confused was that I was trying to inject an interface that was not registered in MAUI startup. Obviously this throws an exception, but this exception is NOT caught by the ErrorBoundary(despite the component being the "thing" that is doing the injecting). These DI-related exceptions aren't caught by anything except AppDomain.CurrentDomain.FirstChanceException, at least as far as I know.

For now, we are going to write a custom handler for FirstChanceException that ignores everything except the DI-related errors. When a DI-related error happens, we will do something to indicate an unrecoverable error has occurred.

If you've got other tools/suggestions available please let me know!

[SeriousM]

For now, we are going to write a custom handler for FirstChanceException that ignores everything except the DI-related errors. When a DI-related error happens, we will do something to indicate an unrecoverable error has occurred.

Handling FirstChangeExceptions is very resource intensive because of the massive amount of events. This is not the place to talk about your implementation, but a warning for other developers: consider unsubscribe from this event once you know that the application runs in a well enough state.

[Forestbrook]

Solution for iOS

For iOS we use the solution described in Issues with unhandled exceptions.

In the AppDelegate we added this code:

public override bool FinishedLaunching(UIApplication application, NSDictionary launchOptions)
{
    Runtime.MarshalManagedException += (_, e) => e.ExceptionMode = MarshalManagedExceptionMode.UnwindNativeCode;
    Runtime.MarshalObjectiveCException += (_, e) => e.ExceptionMode = MarshalObjectiveCExceptionMode.UnwindManagedCode;
    return base.FinishedLaunching(application, launchOptions);
}

Now the handler added with AppDomain.CurrentDomain.UnhandledException += HandleUnhandledException; is called as expected.