ASP.NET Core Global Exception Handling: IExceptionHandler vs Middleware vs Filters — Enterprise Decision Guide

Enterprise teams running ASP.NET Core APIs in production face the same uncomfortable reality: exceptions happen. The real question is not whether they will happen, but how consistently and predictably they are handled across every endpoint, service boundary, and HTTP response. Inconsistent error handling creates debug nightmares, leaks internal details to clients, and produces non-standard error payloads that break downstream consumers. Getting this right — once — is one of the highest-leverage decisions you can make for a long-lived API codebase.

Want implementation-ready .NET source code you can adapt fast? Join Coding Droplets on Patreon. 👉 https://www.patreon.com/CodingDroplets

The Three Approaches and What They Actually Are

Before choosing a strategy, it helps to understand what each mechanism controls and where it sits in the request lifecycle.

Exception-handling middleware operates at the outermost layer of the ASP.NET Core pipeline, before routing, before MVC, before anything framework-specific fires. It wraps every subsequent middleware in a try-catch boundary. When an exception escapes all other handling, middleware catches it and generates a response. Because of its position, it sees every request and every unhandled exception — not just those from MVC actions.

Exception filters (IExceptionFilter / IAsyncExceptionFilter) operate inside the MVC filter pipeline. They only fire for exceptions that propagate out of controller actions, action filters, and result filters. They do not see exceptions from middleware, route resolution failures, or anything that happens before MVC takes ownership. They have access to the full ActionContext — model binding state, controller metadata, route data — which makes them useful when the response depends on MVC-specific context.

IExceptionHandler (introduced in .NET 8) is a registerable abstraction that sits inside the built-in UseExceptionHandler() middleware. You register one or more implementations via AddExceptionHandler<T>(), and ASP.NET Core calls them in registration order, short-circuiting when one handles the exception. It combines the universal coverage of middleware with a cleaner, testable, injectable design — and it integrates natively with AddProblemDetails() for RFC 9457-compliant error responses.

Why the Old Middleware Approach Has Friction

Custom exception-handling middleware was the standard answer for years, and it works reliably. The friction shows at scale:

• Testing requires a full pipeline. Middleware logic is embedded in a RequestDelegate chain, which makes unit testing awkward without integration test scaffolding.
• Multiple exception types scattered across one class. A single middleware tends to grow into a large switch statement or exception-type dispatch chain, becoming a maintenance liability.
• Dependency injection is constrained. Middleware services injected via the constructor are singleton-scoped by default; injecting scoped services requires explicit IServiceProvider resolution inside the handler, which is easy to get wrong.
• Order sensitivity. Developers frequently register exception-handling middleware in the wrong position, causing exceptions from early-pipeline middleware to bypass the handler entirely.

None of these are dealbreakers for small teams, but at enterprise scale — where multiple squads contribute to a shared API, code review cycles are heavy, and test coverage is enforced — they accumulate.

Why Exception Filters Are a Narrow Tool

Exception filters appear attractive because they are familiar to developers who came from ASP.NET 4.x. They also offer a scoped registration model: you can apply a filter globally, per controller, or per action.

The critical limitation is coverage. Exception filters are blind to everything outside the MVC pipeline. This means:

• Exceptions from middleware (custom or built-in) are not caught.
• Failures in service resolution (dependency injection errors at startup or in middleware factories) are not caught.
• Routing failures — 404s from route mismatches — produce default behavior, not your standardized error response.

Enterprise APIs almost always have concerns outside the MVC layer: authentication middleware, rate-limiting middleware, request-body validation pipelines, multi-tenant resolution middleware. Using exception filters as the primary handler leaves gaps that produce inconsistent error responses for clients.

The right use of exception filters is additive and specialized: handling domain exceptions with full access to action metadata, logging controller-scoped context, or producing custom results for specific validation scenarios when model-binding state matters. They should complement, not replace, global handling.

The Enterprise Case for IExceptionHandler in .NET 8+

IExceptionHandler resolves most of the middleware friction without sacrificing coverage. The design forces clean separation: each implementation handles one concern, registered in order, stopping at the first successful handle. This maps well to the way enterprise error taxonomies actually work in practice.

Consider a typical taxonomy:

1. Validation errors → 422 Unprocessable Entity with field-level detail
2. Domain/business rule violations → 409 Conflict or 400 Bad Request with structured reason
3. Authentication/authorization failures → 401/403 with minimal exposure
4. Not Found / resource errors → 404 with stable error codes for client retry logic
5. Unhandled infrastructure errors → 500 with correlation ID and no internal detail

With IExceptionHandler, each of these becomes a focused, injectable, independently testable class. Each class's TryHandleAsync method receives the HttpContext and the Exception, returns true to claim handling, or false to pass to the next handler.

Because implementations are registered with the DI container, they receive scoped dependencies normally — no workarounds needed. This matters when your error handlers need to write to an audit log, increment an observability counter, or check a feature flag before deciding how much detail to expose.

ProblemDetails and RFC 9457: The Enterprise Standard for Error Payloads

Any discussion of error handling strategy in 2026 must include ProblemDetails. The RFC 9457 standard (formerly RFC 7807) defines a structured JSON format for HTTP error responses — type, title, status, detail, instance, plus extension members. When you call builder.Services.AddProblemDetails(), ASP.NET Core wires up the IProblemDetailsService, which IExceptionHandler implementations can use to write RFC-compliant responses.

For enterprise teams, ProblemDetails is not optional. Clients — internal or external — that consume your APIs need predictable error shapes. Front-end teams, mobile consumers, and third-party integrators all benefit from a stable error contract. Ad hoc error bodies that change between endpoints make client error handling fragile and expensive to maintain.

IExceptionHandler combined with AddProblemDetails() gives you that contract with minimal ceremony. You map exceptions to status codes, set detail only when safe to expose, add extension members for correlation IDs or error codes, and let the framework handle serialization.

Decision Matrix: Which Mechanism Belongs Where

Understanding coverage and context of each approach leads to a clear allocation of responsibility:

Global, non-negotiable exception handling → IExceptionHandler (registered via AddExceptionHandler<T>) This is the primary catch-all for every request. It should always be in place and should produce RFC 9457-compliant ProblemDetails.

Pipeline-wide concerns outside MVC → Middleware If you need to intercept exceptions from outside the MVC layer specifically (e.g., a multi-tenant resolution error that is not an MVC action), a lightweight wrapping middleware around that specific concern can complement IExceptionHandler. Avoid building a second general-purpose exception handler.

MVC-scoped, metadata-rich handling → Exception filters Use for specialized scenarios where the exception handler needs controller or action context that is not available in HttpContext alone. Good examples: logging the controller name and action parameters, or producing a custom result type for specific actions.

Validation-specific failures → Model validation + ProblemDetails ASP.NET Core's built-in model validation produces 400 responses via ApiBehaviorOptions. Let this run for model-binding failures and reserve exception handling for domain-level validation that happens after model binding succeeds.

🛡️ From decision to implementation: Knowing which mechanism to use is step one. Wiring it up correctly — mapping NotFoundException to 404, domain violations to 422, never leaking internal details on 500s, and logging at the right severity level for each — is where most implementations fall short. Chapter 6 of the ASP.NET Core Web API: Zero to Production course shows the complete IExceptionHandler implementation as part of a full production API, with typed domain exceptions and the observability integration already connected.

What Changes When You Move to .NET 8+ IExceptionHandler

Teams upgrading from custom middleware or exception filters to IExceptionHandler typically encounter three decisions:

Registration order is the execution order. Your most specific handlers — domain exceptions, known business errors — should register first. The catch-all unhandled exception handler registers last. This mirrors how catch blocks work in C#, and most teams find it intuitive once articulated.

Logging belongs in the handler. With middleware, logging often lived in the middleware body. With IExceptionHandler, inject ILogger<T> directly and log at the appropriate level per exception type — structured, consistent, and testable.

Suppress diagnostic behavior deliberately. In .NET 10, SuppressDiagnosticsCallback gives you fine-grained control over whether ASP.NET Core's diagnostic infrastructure logs the exception again after your handler returns. In earlier versions, double-logging was a common complaint — setting the IExceptionHandlerFeature or using ExceptionHandlerOptions controls this.

Migration Path for Existing Codebases

Enterprise codebases rarely start from scratch. If you have working exception middleware today, the migration path is incremental:

Remove the primary catch-all middleware first and replace it with UseExceptionHandler() plus one or two IExceptionHandler registrations that handle the same cases. Run both approaches in parallel in a staging environment to validate behavioral equivalence. Once satisfied, remove the old middleware.

Exception filters can stay in place. They continue to work alongside IExceptionHandler and provide MVC-specific handling without duplication.

Resist the temptation to migrate everything at once in a single PR. Phased migrations with observable test coverage at each step reduce risk and make rollback straightforward.

Observability Integration

Exception handling is not just about the client response — it is a signal source for your observability stack. Every unhandled exception should emit a metric, increment a counter, and correlate to a trace. With IExceptionHandler, you get a natural injection point for OpenTelemetry instrumentation: inject the ActivitySource, call Activity.Current?.SetStatus(ActivityStatusCode.Error), and add exception tags before writing the response.

The architecture of multiple focused handlers makes it easy to apply observability selectively. You might count domain violations differently from infrastructure failures, and those distinctions drive your alerting thresholds and SLO definitions.

Frequently Asked Questions

Can I use both IExceptionHandler and custom middleware for exception handling in the same app? Yes, but deliberately. IExceptionHandler should be your primary global handler. Custom middleware can supplement it for concerns outside the MVC pipeline, such as request body processing errors or multi-tenant middleware failures. Do not create two competing global handlers — it leads to duplicate responses or logging inconsistencies.

Does IExceptionHandler work with Minimal APIs, or only with controller-based APIs? It works with both. IExceptionHandler operates at the middleware layer and is not coupled to MVC or controller routing. Minimal API endpoints that throw exceptions are caught by UseExceptionHandler() and dispatched to registered IExceptionHandler implementations in the same way as controller actions.

What is the performance cost of IExceptionHandler compared to a try-catch in each action? Exceptions are inherently expensive in .NET — the cost is stack trace collection and CLR unwinding, not the dispatch mechanism. The performance difference between IExceptionHandler, middleware, and filters for the same exception type is negligible in practice. The real cost is the exception itself. This should not factor into your architectural choice.

How do I prevent internal exception details from leaking to clients in production? In IExceptionHandler implementations, control what goes into the ProblemDetails.Detail field explicitly. For unhandled exceptions, detail should contain only a generic message — "An unexpected error occurred" — plus a correlation ID. Never populate detail with exception.Message directly in production. Use environment checks (IHostEnvironment.IsProduction()) or a dedicated configuration flag if you want verbose detail in non-production environments only.

Should exception handling strategies differ between internal APIs and public APIs? The handler implementations differ, but the registration pattern does not. Public APIs need minimal information in error bodies — status code, type, and a stable error code are sufficient. Internal APIs can surface more detail, including service names and component identifiers, because the consumer set is controlled. The simplest implementation is two IExceptionHandler sets — one per exposure profile — activated via configuration.

Can exception filters still call IExceptionHandler implementations? No, exception filters are invoked through a different pipeline path. If a filter handles an exception by returning an IActionResult, IExceptionHandler is not invoked for that exception. The two mechanisms are parallel. Plan your taxonomy accordingly: exceptions that need MVC context go to filters; everything else should propagate to IExceptionHandler.

How does IExceptionHandler interact with UseStatusCodePages? UseStatusCodePages intercepts responses with status codes in the 400–599 range that have no body. IExceptionHandler sets both the status code and the body. If you use both, exception-handler responses will not be re-processed by UseStatusCodePages, because the response body is already written. Non-exception status code responses — for example, a controller returning NotFound() with no body — will still be processed by UseStatusCodePages if enabled.