Expose the UnhandledException event

[jtleaming]

Background and Motivation

In our blazor server application we catch global errors in our system and report back, so our team knows when a user has encountered an unintended error. However, circuit exceptions are ones we are unable to monitor. So when a user gets a circuit exception we have trouble tracing back the original problem. I would like it if the UnhandledExcpetion in the CurcuitHost or Renderer was a publicly available event, or triggered a publicly available event somewhere else, so our app could intercept the exception and log it as desired.

Proposed API

This is just based on current code implementation. The event could also be exposed via a public interface, I'm just not sure where that would best be housed. I also assume this would be only for server side and not be used in WASM.

public sealed class Circuit
{
    private readonly CircuitHost _circuitHost;

    internal Circuit(CircuitHost circuitHost)
    {
        _circuitHost = circuitHost;
+       _circuitHost.UnhandledException += UnhandledExcpetion();
    }

    /// <summary>
    /// Gets the identifier for the <see cref="Circuit"/>.
    /// </summary>
    public string Id => _circuitHost.CircuitId.Id;
+  public event UnhandledExceptionEventHandler UnhandledExcpetion;

+    public void UnhandledExcpetionCalled()
+    {
+        UnhandledExcpetion.Invoke();
+  }
}

Usage Examples

Host.cs

protected override async Task OnInitializedAsync()
{
    var circuit = serviceProvider.GetRequiredService<Circuit>();
    cirucit.UnhandledExcpetion += SendError;
}

private void SendError(Excpetion e)
{
    //Whatever necessary handling of excpetion
}

Alternative Designs

This could also be an interface which listens to the Renderer or CircuitHost for unhandled exceptions. Something managed by DI to expose the event.

Risks

No risks to my knowledge. Potential pitfalls could be someone trying to respond to an unhandled exception poorly, but I think this is something users should be allowed to make a choice on.

[MihuBot]

Possible related and/or duplicate issues:

• Global exception handling #13452
• Notify Unhandled Circuit Exception #55027

[javiercn]

@jtleaming thanks for contacting us.

Is there a reason logging doesn't work for you? That's the way we expose this information. You can either rely on the standard logging or create your own specialized logger to capture these events in more detail. That's the way we recommend doing this.

[jtleaming]

Hi @javiercn, thanks for getting back to me.

We wanted an approach similar to what we are doing in our ErrorBoundaries. Whenever a user gets redirected to the ErrorBoundary we are sending a notification to the development team so they can collect pertinent information regarding the error and quickly investigate. We wanted similar behavior for circuit errors.

We did as you suggested, however something about the approach feels hacky. It would be ideal if there was a more framework exposed way to capture these errors, similar to what ErrorBoundaries gives us.

This is the code I used as an example...

public class InternalLogFactory(
    IServiceProvider serviceProvider, 
    IConfiguration configuration,
    IServiceProvider provider) : ILoggerFactory
{
    private readonly LoggerFactory factory = new(
        serviceProvider.GetServices<ILoggerProvider>(),
        serviceProvider.GetRequiredService<IOptionsMonitor<LoggerFilterOptions>>());

    public void AddProvider(ILoggerProvider provider) => factory.AddProvider(provider);

    public ILogger CreateLogger(string categoryName)
    {
        if (categoryName == "Microsoft.AspNetCore.Components.Server.Circuits.CircuitHost")
        {
            return new CircuitLogger(factory, configuration, provider);
        }
        return factory.CreateLogger(categoryName);
    }

    public void Dispose() => factory.Dispose();
}

Then our CircuitLogger is where we are actively capturing the errors and communicating to our team.

Maybe something is wrong in our approach, but checking the category name to create our specific logger feels brittle to future changes. Given there is already an event being triggered for these errors, and specifically for the unhandled circuit exceptions, exposing the underlying Circuit event would feel like a safer approach.

Please let me know your thoughts and if I can provide any additional context.

All the best!

[javiercn]

@jtleaming thanks for the additional details.

You could use a logger provider, couldn't you?

public sealed class CircuitLoggerProvider(IServiceProvider  serviceProvider) : ILoggerProvider
{
    private const string CircuitHostCategory = "Microsoft.AspNetCore.Components.Server.Circuits.CircuitHost";

    public ILogger CreateLogger(string categoryName) => categoryName == CircuitHostCategory
            ? new CircuitLogger(serviceProvider) : null;

    public void Dispose() {}
}

https://learn.microsoft.com/en-us/dotnet/core/extensions/custom-logging-provider#custom-logger-provider

We are keen on exposing public API that we can't take back, especially when there are already alternatives that we believe are suitable for this. In this case, this is some form of diagnostics/alerts that is essentially the "domain" of logging.

[jtleaming]

Hi @javiercn. While a log provider is certainly another approach to accomplishing the task, I believe it's ultimately a suboptimal solution. My core assertion is this: Blazor gives us a way to handle non-circuit related errors globally via ErrorBoundary. It stands to reason there should also be a built in, global mechanism for circuit bound errors to be handled globally, especially given their severity.

Relying on a logger which depends on a magic string feels fragile and inelegant. Furthermore, I believe that these errors go beyond the domain of logging, This is more than alerts or diagnostics, because the side effects of these errors is circuit termination. That's a critical failure state, and it deserves a pathway for escalation or recovery, not just passive logging.

I understand the caution around exposing internals or introducing mechanisms that might conflict with broader design principles. But beyond the existing alternatives, are there other downsides to enabling a more robust, centralized error handing strategy for circuit-bound failures?