Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In ASP.NET Core, use the Developer Exception Page for diagnostics during development and configure UseExceptionHandler for unhandled failures in production. Add IExceptionHandler when known exception types need centralized responses, and use AddProblemDetails when an API should return a standardized error body. These options work together; the right setup depends on whether the response is for developers or clients and whether your application needs specific error mappings.
Choose the right exception-handling approach
| Approach | Best suited to | Key behavior |
|---|---|---|
| Developer Exception Page | Local development diagnostics | Shows detailed information about exceptions thrown by later middleware. |
UseExceptionHandler |
Production fallback handling | Catches and logs unhandled exceptions; can re-execute the request through an alternate pipeline or use another configured fallback. |
IExceptionHandler |
Centralized handling of known exception types | Registered handlers run in order and can write a response for exceptions they recognize. |
AddProblemDetails |
Machine-readable API error responses | Registers the default Problem Details service for supported error-handling middleware. |
These are not mutually exclusive. A production application can use exception-specific handlers first and a general fallback for anything they do not handle.
Use detailed exception output only in development
The Developer Exception Page is intended for development, not public production responses. It can expose stack traces and request details such as query values, cookies, headers, and endpoint metadata. Current WebApplication.CreateBuilder templates enable it in the Development environment. Microsoft also notes that the page may not show complete information, so use logging for full diagnostic records.
See Microsoft’s ASP.NET Core error-handling guidance for environment-specific middleware behavior.
#1 Best Overall
Configure a production fallback with UseExceptionHandler
A path-based fallback is a common choice when an application has an error page or endpoint:
var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
}
app.MapControllers();
app.Run();Place exception handling early enough in the pipeline to catch failures from middleware that follows it. When the response has not started, the middleware re-executes the request using the configured error path. If that alternate pipeline throws, the middleware rethrows the original exception. If an error page is unsuitable, configure a fallback handler or Problem Details instead.
Rank #2
Calling UseExceptionHandler() without a path or inline handler requires a configured fallback, such as AddProblemDetails; otherwise the application fails during startup. Registered IExceptionHandler implementations run before that fallback.
Recommended Free Tools
Handle known exceptions with IExceptionHandler
Implement IExceptionHandler.TryHandleAsync(HttpContext, Exception, CancellationToken) when exception types need centralized, deliberate responses. Register each implementation with AddExceptionHandler<T> and also add exception-handling middleware with UseExceptionHandler. Registration alone does not activate the handlers. The API is documented for ASP.NET Core 8.0, 9.0, and 10.0 in the IExceptionHandler reference.
Rank #3
Handler order and return values
- Handlers are singleton services and are called in registration order.
- Return
falsewhen a handler does not own the exception; the next handler or configured fallback can run. - Return
trueonly after handling the exception. That stops further handlers, and your implementation must write the complete response, including a deliberate status code and body.
A handled exception with no status or body can result in a 404 and a middleware log. Set the status explicitly and write the response, or use IProblemDetailsService to create the body.
Return Problem Details from an API
Calling AddProblemDetails registers ASP.NET Core’s default IProblemDetailsService. Exception-handling middleware can use it to generate a Problem Details response when no custom handler supplies the response. Status-code pages can also provide a body for otherwise bodyless 4xx and 5xx responses.
builder.Services.AddProblemDetails();
var app = builder.Build();
app.UseExceptionHandler();
app.UseStatusCodePages();By default, the writer supports application/json. Generation depends on the request’s Accept header allowing a supported writer content type; if it excludes supported types, a Problem Details body may not be generated. Applications can customize the service and writers to meet their API contract. Problem Details is a commonly used format, not a requirement: keep public fields safe and make the status and body match the contract clients rely on. See Microsoft’s ASP.NET Core API error-handling documentation.
Free tools Windows power users keep installed
One-click scans. No signup required.
Account for the .NET 10 diagnostics change
In .NET 10, an exception that an IExceptionHandler reports as handled no longer produces diagnostics by default. If an application needs the .NET 8 and 9 behavior, configure SuppressDiagnosticsCallback to return false:
Best Value
- Applying all key ASP.NET Core components, including MVC for HTML generation, .NET Core, EF Core, ASP.NET Identity, dependency injection, and more
- Integrating ASP.NET Core with leading client-side frameworks, including Bootstrap
- ASP.NET Core code for implementing business logic and data transformations
- Handling configuration, routing, controllers, views, and common tasks (including posting forms and presenting data)
- Performing complementary tasks: error handling, logging, application design, authentication, localization, and more
app.UseExceptionHandler(new ExceptionHandlerOptions
{
SuppressDiagnosticsCallback = _ => false
});The callback can also make a conditional decision based on exception or request context. Review the .NET 10 exception diagnostics change when upgrading, especially if telemetry depends on diagnostics emitted for handled exceptions.
Check the response and logging behavior
- Keep detailed exception diagnostics out of public production responses.
- Confirm each custom handler sets an intentional status and writes its response before returning
true. - Test both requests that accept
application/jsonand those whoseAcceptheader excludes supported Problem Details writers. - For path-based handling, verify the error path works when the original response has not started and does not throw a second exception.
- When changing framework versions, verify that handled exceptions still produce the telemetry your application expects.
For the broader ASP.NET Core diagnostics API surface, see Microsoft’s diagnostics namespace reference.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
