A middleware for centralized exception handling as a convention in ASP.NET Core applications.
GlobalExceptionHandler.NET is a middleware library for ASP.NET Core that centralizes exception handling across web applications. It allows developers to define error responses as a convention in the request pipeline, eliminating repetitive try-catch blocks in controllers. The library provides configurable mappings for specific exceptions, content negotiation support, and logging hooks.
ASP.NET Core developers building web APIs or applications who want to implement consistent, centralized error handling without cluttering controller code.
Developers choose GlobalExceptionHandler.NET for its simplicity in setting up convention-based exception handling, reducing boilerplate while offering flexibility for custom error responses and integration with ASP.NET Core MVC features like content negotiation.
Exception handling as a convention in the ASP.NET Core request pipeline
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Allows defining all exception handling logic in Startup.cs, eliminating repetitive try-catch blocks in controllers as shown in the bare bones setup example.
Enables mapping specific exceptions like RecordNotFoundException to custom HTTP status codes and response bodies, providing tailored error responses without controller clutter.
Integrates with ASP.NET Core MVC to format error responses in JSON or XML based on client Accept headers, though it requires the additional GlobalExceptionHandler.ContentNegotiation.Mvc package.
Offers an OnError endpoint to log exceptions to preferred aggregators, facilitating error tracking without modifying controller code, as demonstrated in the logging section.
Cannot be used alongside ASP.NET Core's built-in UseExceptionHandler middleware, limiting integration with existing custom exception handling setups that rely on it.
Advanced features like content negotiation require the MVC framework and an extra NuGet package, adding unnecessary complexity for simple API projects that don't need MVC.
As applications grow with many custom exceptions, the configuration in Startup.cs can become large and cumbersome to maintain, with no built-in modularity or grouping support.