App.UnhandledException doesn't catch exception in WinUI 3.

[Arunkumar5006]

Describe the Issue
Unable to catch UnhandledException in WinUI 3 app. This App.UnhandledException caught the exceptions on UWP but doesn't in the WInUI 3 app.

Code used

public App()
{
this.InitializeComponent();
this.UnhandledException += App_UnhandledException;
}

private void App_UnhandledException(object sender, Microsoft.UI.Xaml.UnhandledExceptionEventArgs e)
{
            Debug.WriteLine("Exception catched");
}

Expected solution
Is there any alternative available for App.UnhandledException event handler to catch the unhandled exceptions that work on WinUI 3 app.

[BenJKuhn]

I don't know that there's a single easy answer in a desktop app. There are many types of exceptions and many ways to register handlers in different languages and frameworks. But there is the unhandledexception API, and it should have a clearly defined & predictable behavior with regards to what it traps.

It's probably most productive to look at your specific scenario. Can you describe the exception that you think it should be catching that it isn't?

Ben

[Arunkumar5006]

Hi,
It catches the "Object reference not set to an instance of an object" and "Specified cast is not valid" exception in our code base. Even though we have given e.Handled = true, the exception is not handled and the app crashes. the stack trace is also null.

It didn't catch the "File not found exception" and "throw new exception" when trying to catch.

[bennoremec]

See also microsoft/microsoft-ui-xaml#5221

[JonPerkinsOldGit]

I agree. A big bugbear for me has been pulling up strings from a resource file. I want my app to be fully internationalisable so I pull up everything at run time, either from ResourceLoader (c#) or x:Uid (XAML). The implementation of text resources is a bit fiddly to keep accurate and it is easy to make a mistake. I have written a common wrapper around the C# call to ResourceLoader with try/catch but this is not possible with XAML. If the specified string is not found in the x:Uid value and the app is being run from the development environment then the error is quietly handled and there is no visible indication of a fault. However, when the app is run as an EXE then as soon as the problem XAML is processed then the app just unloads. There is no trappable error, and the compiler does not provide a warning.

I've had this several times since Win Reunion 0.5 (but most recently early March 2022 with Win App SDK 1.0) and it has cost me quite a few hours to untangle - originally I has no idea what the fault was and it was my first app development away from win forms so I rebuilt the entire app file by file in order to track it down. Of course it takes a while to even come to the conclusion that a resource fault is the culprit, it just unloads! (OK, on a separate issue I will one day learn how to perform crash dump analysis).

As I write this I realise that a workaround would be to remove all x:Uid code and set everything in the .cs file, but I shouldn't need to workaround - I would expect the dev environment to be of practical help here.

[schubi531]

I don't have a workaround for the overall UnhandledException issue. But I found a way around the app silently failing because of a typo in the string resource file. I surround every call to InitializeComponent() with a try-catch block that catches XamlParseExceptions. The XamlParseException.Data dictionary contains information that can help pinpoint the problem.

Example:

try {
    InitializeComponent();
}
catch (XamlParseException parseException) {
    Log.Fatal(parseException, "Unhandled XamlParseException in SettingsPage: {ExceptionMessage}", parseException.Message);
    foreach (var key in parseException.Data.Keys) {
        Log.Fatal("{Key}:{Value}", key.ToString(), parseException.Data[key]?.ToString());
    }
    throw;
}

[JonPerkinsOldGit]

Excellent, that's a really useful bit of code - thank you for posting that Peter.

I raised this issue in the September monthly WinUI Community Call on YouTube and Scott Jones said that there is some work being done on this issue.