429

I am using ASP.NET Core for my new REST API project after using regular ASP.NET Web API for many years. I don't see any good way to handle exceptions in ASP.NET Core Web API. I tried to implement an exception handling filter/attribute:

public class ErrorHandlingFilter : ExceptionFilterAttribute
{
    public override void OnException(ExceptionContext context)
    {
        HandleExceptionAsync(context);
        context.ExceptionHandled = true;
    }

    private static void HandleExceptionAsync(ExceptionContext context)
    {
        var exception = context.Exception;

        if (exception is MyNotFoundException)
            SetExceptionResult(context, exception, HttpStatusCode.NotFound);
        else if (exception is MyUnauthorizedException)
            SetExceptionResult(context, exception, HttpStatusCode.Unauthorized);
        else if (exception is MyException)
            SetExceptionResult(context, exception, HttpStatusCode.BadRequest);
        else
            SetExceptionResult(context, exception, HttpStatusCode.InternalServerError);
    }

    private static void SetExceptionResult(
        ExceptionContext context, 
        Exception exception, 
        HttpStatusCode code)
    {
        context.Result = new JsonResult(new ApiResponse(exception))
        {
            StatusCode = (int)code
        };
    }
}

And here is my Startup filter registration:

services.AddMvc(options =>
{
    options.Filters.Add(new AuthorizationFilter());
    options.Filters.Add(new ErrorHandlingFilter());
});

The issue I was having is that when an exception occurs in my AuthorizationFilter it's not being handled by ErrorHandlingFilter. I was expecting it to be caught there just like it worked with the old ASP.NET Web API.

So how can I catch all application exceptions as well as any exceptions from Action Filters?

3
  • 7
    Have you tried UseExceptionHandler middleware?
    – Pawel
    Commented Aug 3, 2016 at 9:54
  • Just as an option, try handling NotFound without throwing exceptions. NuGet package like github.com/AKlaus/DomainResult would help here.
    – Alex Klaus
    Commented Nov 24, 2021 at 0:58
  • 1
    @AlexKlaus it's way too much noise in code.. I would never recommend it to anyone.
    – Andrei
    Commented Nov 24, 2021 at 12:06

13 Answers 13

781

Latest ASP.NET 8+

Implement interface IExceptionHandler. You can inject logger and other dependencies in constructor.

using Microsoft.AspNetCore.Diagnostics;

class MyExceptionHandler : IExceptionHandler
{
    public async ValueTask<bool> TryHandleAsync(
        HttpContext httpContext, 
        Exception exception, 
        CancellationToken cancellationToken)
    {
        // Your response object
        var error = new { message = exception.Message };
        await httpContext.Response.WriteAsJsonAsync(error, cancellationToken);
        return true;
    }
}

Once you have your IExceptionHandler implementation, simply register this middleware:

builder.Services.AddExceptionHandler<MyExceptionHandler>();

app.UseExceptionHandler(_ => {});
  • You can add multiple IExceptionHandler implementations, and they will be called in the order of registration.
  • Return true from TryHandleAsync if exception is handled, or return false and it will be passed to the next handler.
33
  • 5
    I have been beating my head against the desk trying to get a custom middleware to work today, and it works basically the same way (I'm using it to manage unit of work/transaction for a request). The problem I'm facing is that raised exceptions in 'next' are not caught in the middleware. As you can imagine, this is problematic. What am I doing wrong/missing? Any pointers or suggestions?
    – brappleye3
    Commented Feb 17, 2017 at 2:43
  • 10
    @brappleye3 - I figured out what the problem was. I was just registering the middleware in the wrong place in the Startup.cs class. I moved app.UseMiddleware<ErrorHandlingMiddleware>(); to just before app.UseStaticFiles();. The exception seems to be caught correctly now. This leads me to believe app.UseDeveloperExceptionPage(); app.UseDatabaseErrorPage(); app.UseBrowserLink(); Do some internal magic middleware hackery to get the middleware ordering right.
    – Jamadan
    Commented Mar 28, 2017 at 10:36
  • 4
    I agree that custom middleware can be very useful but would question using exceptions for NotFound, Unauthorised and BadRequest situations. Why not simply set the status code (using NotFound() etc.) and then handle it in your custom middleware or via UseStatusCodePagesWithReExecute? See devtrends.co.uk/blog/handling-errors-in-asp.net-core-web-api for more info
    – Paul Hiles
    Commented May 25, 2017 at 19:35
  • 4
    It's bad because it's always serializing to JSON, completely ignoring content negotiation.
    – Konrad
    Commented Sep 18, 2018 at 10:14
  • 9
    @Konrad valid point. That's why I said that this example is where you can get started, and not the end result. For 99% of APIs JSON is more than enough. If you feel like this answer isn't good enough, feel free to contribute.
    – Andrei
    Commented Sep 18, 2018 at 11:52
133

There is a built-in middleware for that:

ASP.NET Core 5 version:

app.UseExceptionHandler(a => a.Run(async context =>
{
    var exceptionHandlerPathFeature = context.Features.Get<IExceptionHandlerPathFeature>();
    var exception = exceptionHandlerPathFeature.Error;
    
    await context.Response.WriteAsJsonAsync(new { error = exception.Message });
}));

Older versions (they did not have WriteAsJsonAsync extension):

app.UseExceptionHandler(a => a.Run(async context =>
{
    var exceptionHandlerPathFeature = context.Features.Get<IExceptionHandlerPathFeature>();
    var exception = exceptionHandlerPathFeature.Error;
    
    var result = JsonConvert.SerializeObject(new { error = exception.Message });
    context.Response.ContentType = "application/json";
    await context.Response.WriteAsync(result);
}));

It should do pretty much the same, just a bit less code to write.

Important: Remember to add it before MapControllers \ UseMvc (or UseRouting in .Net Core 3) as order is important.

2
  • 2
    Does it support DI as an arg to the handler, or would one have to use a service locator pattern within the handler?
    – l p
    Commented Apr 29, 2020 at 2:16
  • Please check out accepted answer. With that approach you can use DI and you have full control over API response.
    – Andrei
    Commented Feb 28, 2021 at 12:56
37

Your best bet is to use middleware to achieve logging you're looking for. You want to put your exception logging in one middleware and then handle your error pages displayed to the user in a different middleware. That allows separation of logic and follows the design Microsoft has laid out with the 2 middleware components. Here's a good link to Microsoft's documentation: Error Handling in ASP.Net Core

For your specific example, you may want to use one of the extensions in the StatusCodePage middleware or roll your own like this.

You can find an example here for logging exceptions: ExceptionHandlerMiddleware.cs

public void Configure(IApplicationBuilder app)
{
    // app.UseErrorPage(ErrorPageOptions.ShowAll);
    // app.UseStatusCodePages();
    // app.UseStatusCodePages(context => context.HttpContext.Response.SendAsync("Handler, status code: " + context.HttpContext.Response.StatusCode, "text/plain"));
    // app.UseStatusCodePages("text/plain", "Response, status code: {0}");
    // app.UseStatusCodePagesWithRedirects("~/errors/{0}");
    // app.UseStatusCodePagesWithRedirects("/base/errors/{0}");
    // app.UseStatusCodePages(builder => builder.UseWelcomePage());
    app.UseStatusCodePagesWithReExecute("/Errors/{0}");  // I use this version

    // Exception handling logging below
    app.UseExceptionHandler();
}

If you don't like that specific implementation, then you can also use ELM Middleware, and here are some examples: Elm Exception Middleware

public void Configure(IApplicationBuilder app)
{
    app.UseStatusCodePagesWithReExecute("/Errors/{0}");
    // Exception handling logging below
    app.UseElmCapture();
    app.UseElmPage();
}

If that doesn't work for your needs, you can always roll your own Middleware component by looking at their implementations of the ExceptionHandlerMiddleware and the ElmMiddleware to grasp the concepts for building your own.

It's important to add the exception handling middleware below the StatusCodePages middleware but above all your other middleware components. That way your Exception middleware will capture the exception, log it, then allow the request to proceed to the StatusCodePage middleware which will display the friendly error page to the user.

3
37

The well-accepted answer helped me a lot but I wanted to pass HttpStatusCode in my middleware to manage error status code at runtime.

According to this link I got some idea to do the same. So I merged the Andrei Answer with this. So my final code is below:


1. Base class

public class ErrorDetails
{
    public int StatusCode { get; set; }
    public string Message { get; set; }

    public override string ToString()
    {
        return JsonConvert.SerializeObject(this);
    }
}


2. Custom Exception Class Type

public class HttpStatusCodeException : Exception
{
    public HttpStatusCode StatusCode { get; set; }
    public string ContentType { get; set; } = @"text/plain";

    public HttpStatusCodeException(HttpStatusCode statusCode)
    {
        this.StatusCode = statusCode;
    }

    public HttpStatusCodeException(HttpStatusCode statusCode, string message) 
        : base(message)
    {
        this.StatusCode = statusCode;
    }

    public HttpStatusCodeException(HttpStatusCode statusCode, Exception inner) 
        : this(statusCode, inner.ToString()) { }

    public HttpStatusCodeException(HttpStatusCode statusCode, JObject errorObject) 
        : this(statusCode, errorObject.ToString())
    {
        this.ContentType = @"application/json";
    }

}


3. Custom Exception Middleware

public class CustomExceptionMiddleware
{
    private readonly RequestDelegate next;

    public CustomExceptionMiddleware(RequestDelegate next)
    {
        this.next = next;
    }

    public async Task Invoke(HttpContext context /* other dependencies */)
    {
        try
        {
            await next(context);
        }
        catch (HttpStatusCodeException ex)
        {
            await HandleExceptionAsync(context, ex);
        }
        catch (Exception exceptionObj)
        {
            await HandleExceptionAsync(context, exceptionObj);
        }
    }

    private Task HandleExceptionAsync(HttpContext context, HttpStatusCodeException exception)
    {
        string result = null;
        context.Response.ContentType = "application/json";
        if (exception is HttpStatusCodeException)
        {
            result = new ErrorDetails() 
            {
                Message = exception.Message,
                StatusCode = (int)exception.StatusCode 
            }.ToString();
            context.Response.StatusCode = (int)exception.StatusCode;
        }
        else
        {
            result = new ErrorDetails() 
            { 
                Message = "Runtime Error",
                StatusCode = (int)HttpStatusCode.BadRequest
            }.ToString();
            context.Response.StatusCode = (int)HttpStatusCode.BadRequest;
        }
        return context.Response.WriteAsync(result);
    }

    private Task HandleExceptionAsync(HttpContext context, Exception exception)
    {
        string result = new ErrorDetails() 
        { 
            Message = exception.Message,
            StatusCode = (int)HttpStatusCode.InternalServerError 
        }.ToString();
        context.Response.StatusCode = (int)HttpStatusCode.BadRequest;
        return context.Response.WriteAsync(result);
    }
}


4. Extension Method

public static void ConfigureCustomExceptionMiddleware(this IApplicationBuilder app)
{
    app.UseMiddleware<CustomExceptionMiddleware>();
}

5. Configure Method in startup.cs

app.ConfigureCustomExceptionMiddleware();
app.UseMvc();

Now my login method in Account controller :

try
{
    IRepository<UserMaster> obj 
        = new Repository<UserMaster>(_objHeaderCapture, Constants.Tables.UserMaster);
    var result = obj.Get()
        .AsQueryable()
        .Where(sb => sb.EmailId.ToLower() == objData.UserName.ToLower() 
            && sb.Password == objData.Password.ToEncrypt() 
            && sb.Status == (int)StatusType.Active)
        .FirstOrDefault();
    if (result != null)//User Found
        return result;
    else // Not Found
        throw new HttpStatusCodeException(HttpStatusCode.NotFound,
            "Please check username or password");
}
catch (Exception ex)
{
    throw ex;
}

Above you can see if i have not found the user then raising the HttpStatusCodeException in which i have passed HttpStatusCode.NotFound status and a custom message
In middleware

catch (HttpStatusCodeException ex)

blocked will be called which will pass control to

private Task HandleExceptionAsync(HttpContext context, HttpStatusCodeException exception) method


But what if i got runtime error before? For that i have used try catch block which throw exception and will be catched in catch (Exception exceptionObj) block and will pass control to

Task HandleExceptionAsync(HttpContext context, Exception exception)

method.

I have used a single ErrorDetails class for uniformity.

7
  • Where to put extension method? Unfortunately in the startup.cs in void Configure(IapplicationBuilder app) I get an error IApplicationBuilder does not contain a definition for ConfigureCustomExceptionMiddleware. And I added the reference, where CustomExceptionMiddleware.cs is. Commented Jun 4, 2019 at 9:49
  • 3
    you don't want to use exceptions as they slow down your apis. exceptions are very expensive.
    – lnaie
    Commented Oct 4, 2019 at 12:04
  • 2
    @Inaie, Can't say about that... but it seems you have never got any exception to handle to.. Great work Commented Oct 5, 2019 at 19:52
  • 3
    Are you sure to use "throw ex;" instead of "throw;" ?
    – Leszek P
    Commented Jun 2, 2021 at 10:30
  • @LeszekP, i think both will work, though i have not tested it Commented Jun 4, 2021 at 7:59
23

To Configure exception handling behavior per exception type you can use Middleware from NuGet packages:

Code sample:

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    services.AddExceptionHandlingPolicies(options =>
    {
        options.For<InitializationException>().Rethrow();

        options.For<SomeTransientException>().Retry(ro => ro.MaxRetryCount = 2).NextPolicy();

        options.For<SomeBadRequestException>()
        .Response(e => 400)
            .Headers((h, e) => h["X-MyCustomHeader"] = e.Message)
            .WithBody((req,sw, exception) =>
                {
                    byte[] array = Encoding.UTF8.GetBytes(exception.ToString());
                    return sw.WriteAsync(array, 0, array.Length);
                })
        .NextPolicy();

        // Ensure that all exception types are handled by adding handler for generic exception at the end.
        options.For<Exception>()
        .Log(lo =>
            {
                lo.EventIdFactory = (c, e) => new EventId(123, "UnhandlerException");
                lo.Category = (context, exception) => "MyCategory";
            })
        .Response(null, ResponseAlreadyStartedBehaviour.GoToNextHandler)
            .ClearCacheHeaders()
            .WithObjectResult((r, e) => new { msg = e.Message, path = r.Path })
        .Handled();
    });
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    app.UseExceptionHandlingPolicies();
    app.UseMvc();
}
21

Firstly, thanks to Andrei as I've based my solution on his example.

I'm including mine as it's a more complete sample and might save readers some time.

The limitation of Andrei's approach is that doesn't handle logging, capturing potentially useful request variables and content negotiation (it will always return JSON no matter what the client has requested - XML / plain text etc).

My approach is to use an ObjectResult which allows us to use the functionality baked into MVC.

This code also prevents caching of the response.

The error response has been decorated in such a way that it can be serialized by the XML serializer.

public class ExceptionHandlerMiddleware
{
    private readonly RequestDelegate next;
    private readonly IActionResultExecutor<ObjectResult> executor;
    private readonly ILogger logger;
    private static readonly ActionDescriptor EmptyActionDescriptor = new ActionDescriptor();

    public ExceptionHandlerMiddleware(RequestDelegate next, IActionResultExecutor<ObjectResult> executor, ILoggerFactory loggerFactory)
    {
        this.next = next;
        this.executor = executor;
        logger = loggerFactory.CreateLogger<ExceptionHandlerMiddleware>();
    }

    public async Task Invoke(HttpContext context)
    {
        try
        {
            await next(context);
        }
        catch (Exception ex)
        {
            logger.LogError(ex, $"An unhandled exception has occurred while executing the request. Url: {context.Request.GetDisplayUrl()}. Request Data: " + GetRequestData(context));

            if (context.Response.HasStarted)
            {
                throw;
            }

            var routeData = context.GetRouteData() ?? new RouteData();

            ClearCacheHeaders(context.Response);

            var actionContext = new ActionContext(context, routeData, EmptyActionDescriptor);

            var result = new ObjectResult(new ErrorResponse("Error processing request. Server error."))
            {
                StatusCode = (int) HttpStatusCode.InternalServerError,
            };

            await executor.ExecuteAsync(actionContext, result);
        }
    }

    private static string GetRequestData(HttpContext context)
    {
        var sb = new StringBuilder();

        if (context.Request.HasFormContentType && context.Request.Form.Any())
        {
            sb.Append("Form variables:");
            foreach (var x in context.Request.Form)
            {
                sb.AppendFormat("Key={0}, Value={1}<br/>", x.Key, x.Value);
            }
        }

        sb.AppendLine("Method: " + context.Request.Method);

        return sb.ToString();
    }

    private static void ClearCacheHeaders(HttpResponse response)
    {
        response.Headers[HeaderNames.CacheControl] = "no-cache";
        response.Headers[HeaderNames.Pragma] = "no-cache";
        response.Headers[HeaderNames.Expires] = "-1";
        response.Headers.Remove(HeaderNames.ETag);
    }

    [DataContract(Name= "ErrorResponse")]
    public class ErrorResponse
    {
        [DataMember(Name = "Message")]
        public string Message { get; set; }

        public ErrorResponse(string message)
        {
            Message = message;
        }
    }
}
1
11

First, configure ASP.NET Core 2 Startup to re-execute to an error page for any errors from the web server and any unhandled exceptions.

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment()) {
        // Debug config here...
    } else {
        app.UseStatusCodePagesWithReExecute("/Error");
        app.UseExceptionHandler("/Error");
    }
    // More config...
}

Next, define an exception type that will let you throw errors with HTTP status codes.

public class HttpException : Exception
{
    public HttpException(HttpStatusCode statusCode) { StatusCode = statusCode; }
    public HttpStatusCode StatusCode { get; private set; }
}

Finally, in your controller for the error page, customize the response based on the reason for the error and whether the response will be seen directly by an end user. This code assumes all API URLs start with /api/.

[AllowAnonymous]
public IActionResult Error()
{
    // Gets the status code from the exception or web server.
    var statusCode = HttpContext.Features.Get<IExceptionHandlerFeature>()?.Error is HttpException httpEx ?
        httpEx.StatusCode : (HttpStatusCode)Response.StatusCode;

    // For API errors, responds with just the status code (no page).
    if (HttpContext.Features.Get<IHttpRequestFeature>().RawTarget.StartsWith("/api/", StringComparison.Ordinal))
        return StatusCode((int)statusCode);

    // Creates a view model for a user-friendly error page.
    string text = null;
    switch (statusCode) {
        case HttpStatusCode.NotFound: text = "Page not found."; break;
        // Add more as desired.
    }
    return View("Error", new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier, ErrorText = text });
}

ASP.NET Core will log the error detail for you to debug with, so a status code may be all you want to provide to a (potentially untrusted) requester. If you want to show more info, you can enhance HttpException to provide it. For API errors, you can put JSON-encoded error info in the message body by replacing return StatusCode... with return Json....

7

Here is the official guideline from Microsoft covering WebAPI and MVC cases for all versions of .NET.

For Web API it suggests redirecting to a dedicated controller end-point to return ProblemDetails. As it may lead to potential exposure in the OpenAPI spec of end-points that aren't meant to be called directly, I'd suggest a simpler solution:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    ...

    app.UseExceptionHandler(a => a.Run(async context =>
    {
        var error = context.Features.Get<IExceptionHandlerFeature>().Error;
        var problem = new ProblemDetails { Title = "Critical Error"};
        if (error != null)
        {
            if (env.IsDevelopment())
            {
                problem.Title = error.Message;
                problem.Detail = error.StackTrace;
            }
            else
                problem.Detail = error.Message;
        }
        await context.Response.WriteAsJsonAsync(problem);
    }));
    ...
}

In this case, we leverage a standard middleware that returns custom details (with a stack trace for dev mode) and avoid creating 'internal' end-points.

P.S. Note that the official guideline relies on IExceptionHandlerPathFeature before .NET v3 and since then (up to v5 as for now) - on IExceptionHandlerFeature.

P.S.S. If you're throwing exceptions from the Domain layer to convert them to 4xx code, I'd suggest either using the khellang's ProblemDetailsMiddleware or returning DomainResult that can be later converted to IActionResult or IResult. The later option helps you to achieve the same result without the overhead of exceptions.

3
  • 2
    I like this because it's simple and seems to work--just add the code above and you have an instant global exception handler. Note: If you're using app.UseDeveloperExceptionPage(), don't forget to remove it for this and similar solutions to work. Commented Jul 2, 2022 at 21:43
  • I noticed however that the exception handler was not invoked when throwing from a thread other than the main one. So for this case I'm using a simple try/catch in my new thread as a workaround (in order to log the exception). Maybe there is a better way. Commented Jul 3, 2022 at 14:42
  • 2
    Just tested it and it DOES handle exceptions thrown from other threads (and I checked the Thread.CurrentThread.ManagedThreadIds for this claim). Your case is more likely to have another causation (e.g. an exception mapping middleware). Also, pay attention to the registering order of middlewares as emphasised in this SO post.
    – Alex Klaus
    Commented Jul 16, 2022 at 9:23
6

Update ASPNET 8+ with IExceptionHandler

In Nov 2023, aspnet core 8 introduced a new preferred path for exception handling using IExceptionHandler. This is covered on their fundamentals guide on how to Handle errors in ASP.NET core

Create a class that implements IExceptionHandler which requires a single method ValueTask<bool> TryHandleAsync. If you have handled the exception, return true, otherwise, return false to let the next handler attempt if you'd like to chain more than one.

using Microsoft.AspNetCore.Diagnostics;
using System.Net.Mime;
using Microsoft.AspNetCore.Mvc.Infrastructure;

internal class GlobalExceptionHandler(ILogger<GlobalExceptionHandler> logger,
    ProblemDetailsFactory problemDetailsFactory) : IExceptionHandler
{
    public async ValueTask<bool> TryHandleAsync(HttpContext httpContext, 
        Exception exception, CancellationToken cancellationToken)
    {
        logger.LogError(exception, "Whoopsie");

        var problemDetails = problemDetailsFactory.CreateProblemDetails(httpContext, 
            statusCode: StatusCodes.Status500InternalServerError, 
            detail: exception.Message);

        httpContext.Response.ContentType = MediaTypeNames.Application.ProblemJson;
        httpContext.Response.StatusCode = (int)problemDetails.Status;

        await httpContext.Response.WriteAsJsonAsync(problemDetails, cancellationToken);

        return true;
    }
}

You'll then need to register this handler via middleware like this

builder.Services.AddExceptionHandler<GlobalExceptionHandler>();

app.UseExceptionHandler();

Note 1: You need to call UseExceptionHandler on the app for AddExceptionHandler to work.

Note 2: In this example, we return global exceptions via a Problem Details response. If that's all you wanted to do, you could just add builder.Services.AddProblemDetails(), but creating your own exception handler allows for more customizability.

Note 3: This is the prefered route for global exception handling according to microsoft's guidelines on using Exception Filters:

Prefer middleware for exception handling. Use exception filters only where error handling differs based on which action method is called

Further Reading

2
  • What is the preferred way to specify different IExceptionHandler implementations for different path (routes)?
    – StanT.
    Commented Mar 20, 2024 at 17:33
  • 1
    @StanT., you can register multiple different IExceptionHandlers and simply mark as not handled for the next to check the exception and then throw different types of exceptions in different routes, although Filters are still a good way to provide route level exception handling.
    – KyleMit
    Commented Mar 20, 2024 at 18:00
5

By adding your own "Exception Handling Middleware", makes it hard to reuse some good built-in logic of Exception Handler like send an "RFC 7807-compliant payload to the client" when an error happens.

What I made was to extend built-in Exception handler outside of the Startup.cs class to handle custom exceptions or override the behavior of existing ones. For example, an ArgumentException and convert into BadRequest without changing the default behavior of other exceptions:

on the Startup.cs add:

app.UseExceptionHandler("/error");

and extend ErrorController.cs with something like this:

using System;
using Microsoft.AspNetCore.Diagnostics;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Hosting;

namespace Api.Controllers
{
    [ApiController]
    [ApiExplorerSettings(IgnoreApi = true)]
    [AllowAnonymous]
    public class ErrorController : ControllerBase
    {
        [Route("/error")]
        public IActionResult Error(
            [FromServices] IWebHostEnvironment webHostEnvironment)
        {
            var context = HttpContext.Features.Get<IExceptionHandlerFeature>();
            var exceptionType = context.Error.GetType();
            
            if (exceptionType == typeof(ArgumentException)
                || exceptionType == typeof(ArgumentNullException)
                || exceptionType == typeof(ArgumentOutOfRangeException))
            {
                if (webHostEnvironment.IsDevelopment())
                {
                    return ValidationProblem(
                        context.Error.StackTrace,
                        title: context.Error.Message);
                }

                return ValidationProblem(context.Error.Message);
            }

            if (exceptionType == typeof(NotFoundException))
            {
                return NotFound(context.Error.Message);
            }

            if (webHostEnvironment.IsDevelopment())
            {
                return Problem(
                    context.Error.StackTrace,
                    title: context.Error.Message
                    );
            }
            
            return Problem();
        }
    }
}

Note that:

  1. NotFoundException is a custom exception and all you need to do is throw new NotFoundException(null); or throw new ArgumentException("Invalid argument.");
  2. You should not serve sensitive error information to clients. Serving errors is a security risk.
3
  • I did this to return the same structure as netcore: var result = JsonSerializer.Serialize(new { errorCode = error.ErrorCode, errorDescription = error.ErrorDescription, }); There are some issues with it though, like e.g. TraceId Commented Jul 8, 2020 at 15:00
  • @IlyaChernomordik I guess you are returning the result variable? As you can see in my code, I'm returning a built-in BaseController.ValidationProblem or BaseController.Problem. HTTP 400 response ``` { "type": "tools.ietf.org/html/rfc7231#section-6.5.1", "title": "One or more validation errors occurred.", "status": 400, "detail": "File extension is not permitted.", "traceId": "|79eb7d85-40b4e4f64c19c86f.", "errors": {} } ```
    – r.pedrosa
    Commented Jul 8, 2020 at 17:36
  • 1
    Yep, I know. It's a pain to generate it myself and to have e.g. TraceId right, which they change between versions additionally. So there is no way to use ValidationProblem in the middleware. I have the same problem with custom validation of headers: I'd like to return the response in exactly the same way, but since it's not used directly as a parameter I cannot use attribute validation, and in a middleware I would have to "emulate" ValidationProblem json myself... Commented Jul 8, 2020 at 18:00
4

use middleware or IExceptionHandlerPathFeature is fine. there is another way in eshop

create a exceptionfilter and register it

public class HttpGlobalExceptionFilter : IExceptionFilter
{
  public void OnException(ExceptionContext context)
  {...}
}
services.AddMvc(options =>
{
  options.Filters.Add(typeof(HttpGlobalExceptionFilter));
})
1
  • Thanks a lot for your answer!!! You saved me!! I was implementing IActionFilter interface instead and it was not catching all the exceptions. Changing it to IExceptionFilter worked for me. Thanks a lot! Commented Jun 23, 2022 at 12:48
1

A simple way to handle an exception on any particular method is:

using Microsoft.AspNetCore.Http;
...

public ActionResult MyAPIMethod()
{
    try
    {
       var myObject = ... something;

       return Json(myObject);
    }
    catch (Exception ex)
    {
        Log.Error($"Error: {ex.Message}");
        return StatusCode(StatusCodes.Status500InternalServerError);
    }         
}
1

If you want set custom exception handling behavior for a specific controller, you can do so by overriding the controllers OnActionExecuted method.

Remember to set the ExceptionHandled property to true to disable default exception handling behavior.

Here is a sample from an api I'm writing, where I want to catch specific types of exceptions and return a json formatted result:

    private static readonly Type[] API_CATCH_EXCEPTIONS = new Type[]
    {
        typeof(InvalidOperationException),
        typeof(ValidationException)           
    };

    public override void OnActionExecuted(ActionExecutedContext context)
    {
        base.OnActionExecuted(context);

        if (context.Exception != null)
        {
            var exType = context.Exception.GetType();
            if (API_CATCH_EXCEPTIONS.Any(type => exType == type || exType.IsSubclassOf(type)))
            {
                context.Result = Problem(detail: context.Exception.Message);
                context.ExceptionHandled = true;
            }
        }  
    }

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.