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

title	author	description	monikerRange	ms.author	ms.custom	ms.date	no-loc	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	1/11/2021	Home Privacy Kestrel appsettings.json ASP.NET Core Identity cookie Cookie Blazor Blazor Server Blazor WebAssembly Identity Let's Encrypt Razor SignalR	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.

View or download sample code (How to download)

Developer Exception Page

The Developer Exception Page is a useful tool to get detailed stack traces for server errors. It uses xref:Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware to capture synchronous and asynchronous exceptions from the HTTP pipeline and to generate error responses. To illustrate, consider the following controller action:

[!code-csharp]

Run the following curl command to test the preceding action:

curl -i https://localhost:5001/weatherforecast/chicago

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

In ASP.NET Core 3.0 and later, the Developer Exception Page displays a plain-text response if the client doesn't request HTML-formatted output. The following output appears:

HTTP/1.1 500 Internal Server Error
Transfer-Encoding: chunked
Content-Type: text/plain
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Date: Fri, 27 Sep 2019 16:13:16 GMT

System.ArgumentException: We don't offer a weather forecast for chicago. (Parameter 'city')
   at WebApiSample.Controllers.WeatherForecastController.Get(String city) in C:\working_folder\aspnet\AspNetCore.Docs\aspnetcore\web-api\handle-errors\samples\3.x\Controllers\WeatherForecastController.cs:line 34
   at lambda_method(Closure , Object , Object[] )
   at Microsoft.Extensions.Internal.ObjectMethodExecutor.Execute(Object target, Object[] parameters)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ActionMethodExecutor.SyncObjectResultExecutor.Execute(IActionResultTypeMapper mapper, ObjectMethodExecutor executor, Object controller, Object[] arguments)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeActionMethodAsync>g__Logged|12_1(ControllerActionInvoker invoker)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.<InvokeNextActionFilterAsync>g__Awaited|10_0(ControllerActionInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Rethrow(ActionExecutedContextSealed context)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker.InvokeInnerFilterAsync()
--- End of stack trace from previous location where exception was thrown ---
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeFilterPipelineAsync>g__Awaited|19_0(ResourceInvoker invoker, Task lastTask, State next, Scope scope, Object state, Boolean isCompleted)
   at Microsoft.AspNetCore.Mvc.Infrastructure.ResourceInvoker.<InvokeAsync>g__Logged|17_1(ResourceInvoker invoker)
   at Microsoft.AspNetCore.Routing.EndpointMiddleware.<Invoke>g__AwaitRequestTask|6_0(Endpoint endpoint, Task requestTask, ILogger logger)
   at Microsoft.AspNetCore.Authorization.AuthorizationMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

HEADERS
=======
Accept: */*
Host: localhost:44312
User-Agent: curl/7.55.1

To display an HTML-formatted response instead, set the Accept HTTP request header to the text/html media type. For example:

curl -i -H "Accept: text/html" https://localhost:5001/weatherforecast/chicago

Consider the following excerpt from the HTTP response:

::: moniker-end

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

In ASP.NET Core 2.2 and earlier, the Developer Exception Page displays an HTML-formatted response. For example, consider the following excerpt from the HTTP response:

::: moniker-end

HTTP/1.1 500 Internal Server Error
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
X-Powered-By: ASP.NET
Date: Fri, 27 Sep 2019 16:55:37 GMT

<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta charset="utf-8" />
        <title>Internal Server Error</title>
        <style>
            body {
    font-family: 'Segoe UI', Tahoma, Arial, Helvetica, sans-serif;
    font-size: .813em;
    color: #222;
    background-color: #fff;
}

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

The HTML-formatted response becomes useful when testing via tools like Postman. The following screen capture shows both the plain-text and the HTML-formatted responses in Postman:

::: moniker-end

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

Don't mark the error handler action method with HTTP method attributes, such as HttpGet. Explicit verbs prevent some requests from reaching the action method. Allow anonymous access to the method if unauthenticated users should see the error.

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%2A to use the middleware:

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

   [!code-csharp]

   ::: moniker-end

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

   [!code-csharp]

   ::: moniker-end

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

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

   [!code-csharp]

   ::: moniker-end

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

   [!code-csharp]

   ::: moniker-end

The preceding Error action sends an RFC 7807-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:

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

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

   ::: moniker-end

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

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

   ::: moniker-end

   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:

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

   [!code-csharp]

   ::: moniker-end

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

   [!code-csharp]

   ::: moniker-end

   The preceding code calls ControllerBase.Problem to create a xref:Microsoft.AspNetCore.Mvc.ProblemDetails response.

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:

   [!code-csharp]

2. Create an action filter named HttpResponseExceptionFilter:

   [!code-csharp]

   The preceding filter specifies an Order of the maximum integer value minus 10. This allows other filters to run at the end of the pipeline.

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

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

   [!code-csharp]

   ::: moniker-end

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

   [!code-csharp]

   ::: moniker-end

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

   [!code-csharp]

   ::: moniker-end

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"

[!code-csharp]

::: 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-2.1"

[!IMPORTANT] ASP.NET Core 2.1 generates a problem details response that's nearly RFC 7807-compliant. If 100 percent compliance is important, upgrade the project to ASP.NET Core 2.2 or later.

::: moniker-end

::: 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 xref:Microsoft.AspNetCore.Mvc.Infrastructure.ProblemDetailsFactory?displayProperty=fullName 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 xref:Microsoft.AspNetCore.Mvc.ControllerBase.Problem%2A?displayProperty=nameWithType and xref:Microsoft.AspNetCore.Mvc.ControllerBase.ValidationProblem%2A?displayProperty=nameWithType helper methods.

To customize the problem details response, register a custom implementation of xref:Microsoft.AspNetCore.Mvc.Infrastructure.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

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

Use ApiBehaviorOptions.ClientErrorMapping

Use the xref:Microsoft.AspNetCore.Mvc.ApiBehaviorOptions.ClientErrorMapping%2A property to configure the contents of the ProblemDetails response. For example, the following code in Startup.ConfigureServices updates the type property for 404 responses:

::: moniker-end

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

[!code-csharp]

::: moniker-end

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

[!code-csharp]

::: moniker-end

Custom Middleware to handle exceptions

The defaults in the exception handling middleware works well for most apps. For apps that require specialized exception handling, consider customizing the exception handling middleware.

Producing a ProblemDetails payload for exceptions

ASP.NET Core doesn't produce a standardized error payload when the server encounters an unhandled exception. For scenarios where it is desireable to return a standardized ProblemDetails response to the client, the ProblemDetails middleware can be used to map exceptions and 404s to a ProblemDetails payload. The exception handling middleware can also be used to return a xref:Microsoft.AspNetCore.Mvc.ProblemDetails payload for unhandled exceptions.