ExceptionHandlerMiddleware catches HTTP-pipeline exceptions and sends relevant error information to a configurable handler instead of exposing a detailed error response. section 2.4.3
Use it outside development, where detailed exception pages could reveal stack traces, cookies, headers, configuration details, or vulnerabilities. Configure the middleware with an error route such as /error. section 2.4.3
A practical configuration follows these decisions:
- Enable the developer exception page in development and ExceptionHandlerMiddleware in staging or production. section 2.4.3
- Implement the configured /error handler with either an API controller or a Minimal API endpoint. section 2.4.3
- Return a standardized problem response, such as HTTP 500 with a human-readable error title. section 2.4.3
- Customize handling when needed by mapping exception types to status codes, logging exceptions, or notifying administrators. section 6.4
Route-based error handling
Configure app.UseExceptionHandler("/error") and implement either a controller action returning Problem() or app.MapGet("/error", () => Results.Problem()). Test with a route that throws an exception, then verify the resulting problem response. section 2.4.3
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/error");
}
Shows the environment-based Program.cs branch that selects the developer exception page or ExceptionHandlerMiddleware. section 2.4.3
using Microsoft.AspNetCore.Mvc;
namespace MyBGList.Controllers
{
[ApiController]
public class ErrorController : ControllerBase
{
[Route("/error")] #1
[HttpGet] #2
public IActionResult Error()
{
return Problem(); #3
}
}
}
Shows a controller-based /error endpoint that converts failures into a Problem response. section 2.4.3
