Blazor WebView exception handling behavior inconsistencies

[Eilon]

There are likely inconsistencies and oddities in how various types of exceptions are handled in the various BlazorWebView implementations (or WebViewManagers).

We need to check the behavior from several different types of exceptions:

• Un-awaited task throws
• Render exception
• Event handler exception
• Others?

And the goal is to have them behave as they would if it were an otherwise-equivalent scenario implemented in native UI. There could be exception (ahem) to this, but in general we want to be consistent. For example, if exceptions should normally flow to AppDomain.UnhandledException, that's what should happen. If the platform offers its own "unhandled exception" pattern, we should support that.

[ghost]

Thanks for contacting us.

We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[TanayParikh]

Repros:

Un-awaited task throws

<button @onclick="ThrowExceptionUnawaited">Un-awaited task throws</button>

@code {
    void ThrowExceptionUnawaited()
    {
        _ = ThrowExceptionAsync();
    }

    async Task ThrowExceptionAsync()
    {
        await Task.Delay(10);
        throw new Exception("This is some ***async*** exception.");
    }
}

Render exception

@{
    throw new Exception("Rendering exception.");
}

Event handler exception

<button @onclick="ThrowException">Throw Exception</button>

@code {
    void ThrowException()
    {
        throw new Exception("This is some unhandled exception.");
    }
}

[TanayParikh]

iOS: First one does nothing, the other two throw an unhandled exception (yellow bar).

@Eilon is the goal of this issue to ensure the other platforms exhibit the same behavior as above? Or is the goal to ensure the two unhandled exceptions that yellow bar somehow flow through as NSException / NSError through the app stack?

As a side note, do we need to consider an error recovery mechanism short of closing the app and re-opening. Ex. refresh the webview kind of like what we do for Blazor server reconnect?

[Eilon]

@TanayParikh the goal in general is that various kinds of unhandled exceptions should be obviously visible to the developer (e.g. crash the app, yellow bar, etc.), and also loggable, and perhaps logged by default using ILogger.

So if on iOS some case "does nothing" then that needs to be addressed. Surely it does something, but it's something invisible, so that's a problem.

I'm not sure you really need error recovery per se because if such an exception handles, the app is broken. The dev should have put in their own try/catch to handle the error (they do have a place to do that, right?) and possibly do a retry etc.

[TanayParikh]

Thanks for the clarification Eilon.

So if on iOS some case "does nothing" then that needs to be addressed. Surely it does something, but it's something invisible, so that's a problem.

I definitely agree with the sentiment that unhandled exceptions should be visible to the dev. However, for the un-awaited async throw case specifically, the silent failure is the same behavior that Blazor WASM and even a vanilla C# console application exhibits. As such, I believe our current behavior is inline with developer expectations.

[Eilon]

Ah, sure, I guess there are some cases where it's by-design invisible. But there was the scenario in #3695 (which I re-opened) where some errors that should definitely be visible, are somehow not visible at all.

[javiercn]

@TanayParikh @Eilon based on discussions on #3695 I've captured more details on #4441 which should supersede this issue

[TanayParikh]

Thanks @javiercn, I'm going to close this issue out in favor of #4441.