AspNetCore.Docs/aspnetcore/web-api/handle-errors.md

title	author	description	monikerRange	ms.author	ms.custom	ms.date	uid
Handle errors in ASP.NET Core web APIs	pranavkm	Learn about error handling with ASP.NET Core web APIs.	>= aspnetcore-2.1	prkrishn	mvc	09/18/2019	web-api/handle-errors

Handle errors in ASP.NET Core web APIs

This article describes how to handle and customize error handling with ASP.NET Core web APIs.

Developer Exception Page

The Developer Exception Page is a useful tool to get detailed stack traces for server errors.

::: moniker range=">= aspnetcore-3.0"

The Developer Exception Page displays a plain-text response if the client doesn't accept HTML-formatted output:

> curl https://localhost:5001/weatherforecast
System.ArgumentException: count
   at errorhandling.Controllers.WeatherForecastController.Get(Int32 x) in D:\work\Samples\samples\aspnetcore\mvc\errorhandling\Controllers\WeatherForecastController.cs:line 35
   at lambda_method(Closure , Object , Object[] )
   at Microsoft.Extensions.Internal.ObjectMethodExecutor.Execute(Object target, Object[] parameters)
...

::: moniker-end

[!WARNING] Enable the Developer Exception Page only when the app is running in the Development environment. You don't want to share detailed exception information publicly when the app runs in production. For more information on configuring environments, see xref:fundamentals/environments.

Exception handler

In non-development environments, Exception Handling Middleware can be used to produce an error payload:

1. In Startup.Configure, invoke xref:Microsoft.AspNetCore.Builder.ExceptionHandlerExtensions.UseExceptionHandler* to use the middleware:

   public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
   {
       if (env.IsDevelopment())
       {
           app.UseDeveloperExceptionPage();
       }
       else
       {
           app.UseExceptionHandler("/error");
       }
   }
   

2. Configure a controller action to respond to the /error route:

   [ApiController]
   public class ErrorController : ControllerBase
   {
       [Route("/error")]
       public IActionResult Error() => Problem();
   }
   

The preceding Error action sends an RFC7807-compliant payload to the client.

Exception Handling Middleware can also provide more detailed content-negotiated output in the local development environment. Use the following steps to produce a consistent payload format across development and production environments:

1. In Startup.Configure, register environment-specific Exception Handling Middleware instances:

   public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
   {
       if (env.IsDevelopment())
       {
           app.UseExceptionHandler("/error-local-development");
       }
       else
       {
           app.UseExceptionHandler("/error");
       }
   }
   

   In the preceding code, the middleware is registered with:

   • A route of /error-local-development in the Development environment.
   • A route of /error in environments that aren't Development.

2. Apply attribute routing to controller actions:

   [ApiController]
   public class ErrorController : ControllerBase
   {
       [Route("/error-local-development")]
       public IActionResult ErrorLocalDevelopment(
           [FromServices] IWebHostEnvironment webHostEnvironment)
       {
           if (!webHostEnvironment.IsDevelopment())
           {
               throw new InvalidOperationException(
                   "This shouldn't be invoked in non-development environments.");
           }
   
           var context = HttpContext.Features.Get<IExceptionHandlerFeature>();
   
           return Problem(
               detail: context.Error.StackTrace,
               title: context.Error.Message);
       }
   
       [Route("/error")]
       public IActionResult Error() => Problem();
   }
   

Use exceptions to modify the response

The contents of the response can be modified from outside of the controller. In ASP.NET 4.x Web API, one way to do this was using the xref:System.Web.Http.HttpResponseException type. ASP.NET Core doesn't include an equivalent type. Support for HttpResponseException can be added with the following steps:

1. Create a well-known exception type named HttpResponseException:

   public class HttpResponseException : Exception
   {
       public int Status { get; set; } = 500;
   
       public object Value { get; set; }
   }
   

2. Create an action filter named HttpResponseExceptionFilter:

   public class HttpResponseExceptionFilter : IActionFilter, IOrderedFilter
   {
       public int Order { get; set; } = int.MaxValue - 10;
   
       public void OnActionExecuting(ActionExecutingContext context) {}
   
       public void OnActionExecuted(ActionExecutedContext context)
       {
           if (context.Exception is HttpResponseException exception)
           {
               context.Result = new ObjectResult(exception.Value)
               {
                   Status = exception.Status,
               };
               context.ExceptionHandled = true;
           }
       }
   }
   

3. In Startup.ConfigureServices, add the action filter to the filters collection:

   public void ConfigureServices(IServiceCollection services)
   {
       services.AddControllers(options => 
           options.Filters.Add(new HttpResponseExceptionFilter()));
   }
   

Validation failure error response

For web API controllers, MVC responds with a xref:Microsoft.AspNetCore.Mvc.ValidationProblemDetails response type when model validation fails. MVC uses the results of xref:Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.InvalidModelStateResponseFactory to construct the error response for a validation failure. The following example uses the factory to change the default response type to xref:Microsoft.AspNetCore.Mvc.SerializableError in Startup.ConfigureServices:

::: moniker range=">= aspnetcore-3.0"

[!code-csharp]

::: moniker-end

::: moniker range="= aspnetcore-2.2"

[!code-csharp]

::: moniker-end

::: moniker range="= aspnetcore-2.1"

services.AddMvc()
    .SetCompatibilityVersion(CompatibilityVersion.Version_2_1);

services.Configure<ApiBehaviorOptions>(options =>
{
    options.InvalidModelStateResponseFactory = context =>
    {
        var result = new BadRequestObjectResult(context.ModelState);

        // TODO: add `using using System.Net.Mime;` to resolve MediaTypeNames
        result.ContentTypes.Add(MediaTypeNames.Application.Json);
        result.ContentTypes.Add(MediaTypeNames.Application.Xml);

        return result;
    };
});

::: moniker-end

Client error response

An error result is defined as a result with an HTTP status code of 400 or higher. For web API controllers, MVC transforms an error result to a result with xref:Microsoft.AspNetCore.Mvc.ProblemDetails.

::: moniker range=">= aspnetcore-3.0"

The error response can be configured in one of the following ways:

1. Implement ProblemDetailsFactory
2. Use ApiBehaviorOptions.ClientErrorMapping

Implement ProblemDetailsFactory

MVC uses Microsoft.AspNetCore.Mvc.ProblemDetailsFactory to produce all instances of xref:Microsoft.AspNetCore.Mvc.ProblemDetails and xref:Microsoft.AspNetCore.Mvc.ValidationProblemDetails. This includes client error responses, validation failure error responses, and the Microsoft.AspNetCore.Mvc.ControllerBase.Problem and xref:Microsoft.AspNetCore.Mvc.ControllerBase.ValidationProblem helper methods.

To customize the problem details response, register a custom implementation of ProblemDetailsFactory in Startup.ConfigureServices:

public void ConfigureServices(IServiceCollection serviceCollection)
{
    services.AddControllers();
    services.AddTransient<ProblemDetailsFactory, CustomProblemDetailsFactory>();
}

::: moniker-end

::: moniker range="<= aspnetcore-2.2"

The error response can be configured as outlined in the Use ApiBehaviorOptions.ClientErrorMapping section.

::: moniker-end

Use ApiBehaviorOptions.ClientErrorMapping

Use the xref:Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.ClientErrorMapping* property to configure the contents of the ProblemDetails response. For example, the following code updates the type property for 404 responses:

::: moniker range=">= aspnetcore-3.0"

[!code-csharp]

::: moniker-end

::: moniker range="<= aspnetcore-2.2"

[!code-csharp]

::: moniker-end