How do you handle unhandled exceptions globally in .NET? Explain UseExceptionHandler, IExceptionHandler and ProblemDetails in ASP.NET Core, AppDomain.UnhandledException, TaskScheduler.UnobservedTaskException, BackgroundService failures and async void, and what a good global strategy looks like.

How I would answer this in an interview

A good global strategy has layers: handle expected failures close to where they happen (often without exceptions), let unexpected exceptions bubble to a single boundary per entry point that logs once, returns a safe, consistent response (ProblemDetails) and keeps the process healthy — and make sure background work and fire-and-forget code can't fail silently or crash the host. I'd walk through each mechanism and where it fits.

1. ASP.NET Core: UseExceptionHandler, IExceptionHandler, ProblemDetails

builder.Services.AddProblemDetails(o =>
    o.CustomizeProblemDetails = ctx =>
        ctx.ProblemDetails.Extensions["traceId"] = Activity.Current?.Id ?? ctx.HttpContext.TraceIdentifier);

builder.Services.AddExceptionHandler<ValidationExceptionHandler>();   // order matters
builder.Services.AddExceptionHandler<ConflictExceptionHandler>();
builder.Services.AddExceptionHandler<FallbackExceptionHandler>();     // logs + 500

var app = builder.Build();
app.UseExceptionHandler();      // first in the pipeline so it wraps everything after it
app.UseStatusCodePages();       // ProblemDetails for 404/405 etc. without bodies

• UseExceptionHandler is middleware that catches unhandled exceptions from later middleware/endpoints, clears the response (if not started), and re-executes to produce an error response.
• IExceptionHandler (.NET 8) lets you register multiple handlers in DI; each TryHandleAsync returns true if it handled the exception. Typical handlers map domain exceptions to status codes (404, 409, 422) and a fallback logs and returns 500.
• ProblemDetails (RFC 9457, formerly 7807) gives a consistent JSON error shape: type, title, status, detail, instance, plus extensions such as traceId and validation errors. IProblemDetailsService writes it and respects content negotiation.
• In production, never return exception messages or stack traces to clients (information disclosure, OWASP). UseDeveloperExceptionPage is only for Development.
• If the response has already started (streaming), the handler can't change it; the connection is aborted — design streaming endpoints accordingly.
• Logging: the exception handler middleware logs unhandled exceptions; avoid also logging in each layer.

2. Process-level last resorts

• AppDomain.CurrentDomain.UnhandledException: raised when an exception is unhandled on any thread. It's a notification, not a handler — the process will still terminate. Use it to log/flush telemetry (e.g. Log.CloseAndFlush()), not to recover.
• TaskScheduler.UnobservedTaskException: raised when a faulted Task is garbage-collected without its exception being observed (fire-and-forget). Since .NET 4.5 it doesn't crash the process by default; call e.SetObserved() after logging. Its timing depends on GC, so it's a safety net, not a mechanism.

3. BackgroundService failures

• Since .NET 6, an unhandled exception escaping ExecuteAsync stops the host by default (BackgroundServiceExceptionBehavior.StopHost), logging the error. Before .NET 6 the service died silently while the app kept running.
• That's usually right for critical workers (the orchestrator restarts the container), but a worker loop should handle per-item failures so one bad message doesn't kill the host:

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    await foreach (var message in _channel.Reader.ReadAllAsync(stoppingToken))
    {
        try
        {
            await _processor.HandleAsync(message, stoppingToken);
        }
        catch (OperationCanceledException) when (stoppingToken.IsCancellationRequested)
        {
            break;                                         // shutting down
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Failed to process message {MessageId}", message.Id);
            await _deadLetter.SendAsync(message, ex, stoppingToken);   // don't lose it
        }
    }
}

• Also note that a synchronous, long-running start of ExecuteAsync (before the first await) blocks host start-up — begin with await Task.Yield() or keep the start fast.

4. async void

Exceptions from an async void method can't be caught by the caller — they're posted to the SynchronizationContext or, in ASP.NET Core/console apps, rethrown on the thread pool, which crashes the process via UnhandledException. Rules: never write async void except for event handlers, and wrap their bodies in try/catch. Analysers (VSTHRD100, CA2012-adjacent rules) flag it.

5. Fire-and-forget and other entry points

• _ = Task.Run(...) or un-awaited async calls lose exceptions (and, in ASP.NET Core, may outlive the request's scoped services — ObjectDisposedException on DbContext). Use a background queue (Channel<T> + BackgroundService) with its own error handling, or a durable queue.
• Message consumers (Azure Service Bus, Functions): rely on the platform's retry + dead-letter semantics; catch only to add context or to classify poison messages.
• gRPC: interceptors map exceptions to RpcException status codes. SignalR: hub filters.

6. What a good global strategy looks like

1. Expected outcomes (validation, not found, conflicts) don't use exceptions where possible: result types or validation filters producing ValidationProblemDetails (400/422).
2. Domain exceptions that do occur are mapped by specific IExceptionHandlers to stable ProblemDetails types.
3. Everything else → fallback handler: log once with full exception + trace ID, return generic 500 ProblemDetails.
4. Correlation: include traceId in responses so support can find logs; OpenTelemetry/Application Insights link logs, traces and exceptions.
5. Background workers handle per-item failures, dead-letter poison messages, and let truly fatal errors stop the host so the orchestrator restarts it; health checks reflect worker health.
6. Process safety nets: UnhandledException and UnobservedTaskException logging, with log flushing.
7. Alerting on 5xx rates and specific exception types, not on every logged exception.
8. No sensitive data in error responses or logs (Privacy Act, APP 11).

7. A production example

An API returned three different error shapes (MVC's default, a custom { error: "..." } from a middleware, and raw exception text in some minimal API endpoints), and a background email worker had died silently months earlier because an exception escaped ExecuteAsync under .NET 5 — nobody noticed until customers complained about missing invoices. We standardised on AddProblemDetails + IExceptionHandlers, added traceId to every error response, upgraded the worker (.NET 8's StopHost behaviour plus per-message try/catch and dead-lettering), added a health check reporting the worker's last successful run, and set Application Insights alerts on failed-request rate and on worker health.