Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Global Exception Handling Mechanism for .NET MAUI #5535

Open
3 of 4 tasks
TanayParikh opened this issue Mar 23, 2022 Discussed in #653 · 8 comments
Open
3 of 4 tasks

Support Global Exception Handling Mechanism for .NET MAUI #5535

TanayParikh opened this issue Mar 23, 2022 Discussed in #653 · 8 comments
Labels
area-core-hosting Extensions / Hosting / AppBuilder / Startup partner/cat 😻 this is an issue that impacts one of our partners or a customer our advisory team is engaged with t/enhancement ☀️ New feature or request

Comments

@TanayParikh
Copy link
Contributor

TanayParikh commented Mar 23, 2022

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

@jsuarezruiz jsuarezruiz added the t/enhancement ☀️ New feature or request label Mar 24, 2022
@Eilon Eilon added area-blazor Blazor Hybrid / Desktop, BlazorWebView and removed area-blazor Blazor Hybrid / Desktop, BlazorWebView labels Mar 24, 2022
@jfversluis jfversluis added the area-core-hosting Extensions / Hosting / AppBuilder / Startup label Mar 30, 2022
@emorell96

This comment was marked as off-topic.

@kfrancis

This comment was marked as off-topic.

@ghost
Copy link

ghost commented Aug 24, 2022

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.

@mikeparker104 mikeparker104 added the partner/cat 😻 this is an issue that impacts one of our partners or a customer our advisory team is engaged with label Feb 2, 2023
@ericgrantholland
Copy link

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
Copy link
Member

Redth commented May 11, 2023

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
Copy link

@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
Copy link

SeriousM commented Jun 5, 2023

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-core-hosting Extensions / Hosting / AppBuilder / Startup partner/cat 😻 this is an issue that impacts one of our partners or a customer our advisory team is engaged with t/enhancement ☀️ New feature or request
Projects
None yet
Development

No branches or pull requests