Exception handling is required in any application. It is a very interesing issue where different apps have their own various way(s) to handle that. I plan to write a series of articles to discuss this issue

respectively.

In this article, we will make a summary for ASP.NET MVC and Web API, .Net Framework and Core..

Introduction

In Part (3) of this article seriers, we discussed Exception Handling for ASP.NET Core MVC. Due to the similarities of the Exception Handling between ASP.NET Core MVC and ASP.NET Core Web API, we will follow the pattern of ASP.NET Core MVC.

ASP.NET MVC

MVC is definitely Web App, so the Exception handling is view (page) based. i.e., the exception handling will lead to a error page opened.

We can:

  1. Configure Exception in Web.Config
    • by making customErrors mode="On"
    • by adding error statusCode in Web.Config
  2. Configure Exception by [HandleError] attribute
    • Controller
    • Action:
  3. Configure Exception by filters
    • Global
    • Local
  4. Configure Exception by Application_Error Event in Global.asax:
  5. Configure Exception by Try-Catch

Exception handling files:

where Error.cshuml is default added initially, others are added manually.

The exception handling page is the default one: Error.cshtml.

The exception handling page will go to the defined Controller/View, such as ErrorPage404Controller (need to be added plus View).

The [HandleError] attribute will redirect the relative page when exception happens:

i.e

[HandleError] ==> Error.cshtml
[HandleError(ExceptionType = typeof(DivideByZeroException), View = "Error1")] => Error1.cshtml
[HandleError(ExceptionType = typeof(ArgumentOutOfRangeException), View = "Error2")] => Error2.cshtml

Add filter attribute to controller/action:

or Registered Globally:

The exception handling page will go to Error4.cshtml as defined in the filter.

The exception handling page will go to the ErrorPageController/View as defined.

The exception handling page will go to Error2.cshtml in the shared folder.

ASP.NET Web API

For error handling, the major difference between ASP.NET MVC Web API from MVC or a Web application is that MVC or a Web app will return a web page to handle the error while Web API is to return a RESTfule output, JSON. In ASP.NET MVC Web API, we may have three ways to handle exceptions:

  1. HttpResponseException, associated with HttpStatusCode, --- Locally in Try-catch-final
  2. Exception filter, --- in the level of Action, Controller, and Globally
  3. Exception Handler, --- Globally and Locally

When creating a ASP.NET Web API app, the MVC is selected automatically. So, the Web API app actually is an added on one of the MVC app. Therefore, some features of exception handling for Web API are the exactly same as MVC modue, such as

We will not repeat these parts, and only discuss the 3:

HttpResponseException with HttpStatusCode,

HttpResponseException with HttpResponseMessage:

Define the filter:

Registered locally for either Controller or Action:

Registered Globally in WebApiConfig.cs file

Run

Define the Exception Handler:

Registered Globally:

Registered Locally:

Run

ASP.Net Core MVC

The differences in exception handling between .NET MVC and .NET Core MVC

Core MVC is not like MVC, without Web.Config file, no Global.asax file, no 4 config files under App_Start:

while it has a majoe config file startup.cs to register and run middlewares, and with a launchSettings.json for startup perameters, such as server, port, environment settings, and an appsettings.json for parameters such as database connections:

Exception filters are useful for trapping exceptions that occur within MVC actions, but they're not as flexible as the built-in exception handling middleware, UseExceptionHandler. Microsoft recommend using UseExceptionHandler, unless you need to perform error handling differently based on which MVC action is chosen.

For production, from Exception Handling (3), in ASP.NET Core MVC, we have:

Start the discussion:

Exception Handler Page

Exception Handler Lambda:

UseStatusCodePages,

UseStatusCodePages, and with format string, and with Lambda

UseStatusCodePages, and with format string, and with Lambda

Register locally:

Register Globally

Run

ASP.NET Core Web App.

Finally, I would like to make a point that our discussions in this article, Exception Handling for ASP.NET Core MVC, are suitable for ASP.NET Core Web app, because the structure of ASP.NET Core MVC app and ASP.NET Core Web app are quite similar. If we compare the startup file for both Core MVC app and Core Web app, we can see that:

There are only three differences in the startup codes, they are all not structure difference, they are all for views. The first difference indicates AddControllers() for web app, and AddControllersWithViews() for MVC:

The second one just directs the error handling page to diffrent places:

And the third one is related to endpoints, the routing:

app. UseEndpoints(endpoints app. UseEndpoint5(endpoint5 "default" , n;

Therefore, in exception handling, Web App and MVC App are the same, we can apply our discussion for MVC to Web App.

References