【连载7】 C# MVC 跨框架异常处理对比：.NET Framework 与 .NET Core 实现差异

异常处理是任何应用程序的关键部分，尤其在 MVC 架构中，统一的异常处理机制能极大提升代码可维护性。下面通过代码示例对比 .NET Framework 与 .NET Core 在 MVC 异常处理上的实现差异

1. 全局异常处理实现

迁移到 .NET Core 的异常处理挑战

从 .NET Framework 迁移到 .NET Core 时，异常处理机制的差异可能带来以下挑战：

HTTP 管道差异

在 .NET Framework 中，Global.asax 和 HttpApplication 的 Application_Error 是全局异常处理的主要方式。而 .NET Core 采用中间件（Middleware）模式，需使用 UseExceptionHandler 或自定义中间件捕获异常，迁移时需调整代码结构。

异步代码支持

.NET Core 更强调异步编程，未处理的异步异常可能导致进程崩溃。需确保 async/await 方法中异常被正确捕获，或通过 TaskScheduler.UnobservedTaskException 处理未观察的任务异常。

依赖注入集成

.NET Core 内置 DI 容器，异常处理中间件可能依赖注入的服务。需在中间件中正确解析服务，例如通过构造函数注入或 HttpContext.RequestServices。

日志记录变化

.NET Framework 中常用 System.Diagnostics.Trace 或第三方日志库，而 .NET Core 推荐使用 ILogger 接口。迁移时需重构日志记录逻辑，确保异常信息被正确输出到控制台、文件或第三方平台（如 Serilog）。

其他关键差异点

Kestrel 与 IIS 集成

.NET Core 默认使用 Kestrel 作为 Web 服务器，异常处理行为可能与 IIS 不同。例如，Kestrel 对请求超时或连接中断的响应方式需特别配置。

配置文件转换
web.config 被 appsettings.json 替代，异常处理相关的配置（如自定义错误页面路径）需迁移到新格式，并通过代码加载。

跨平台兼容性

.NET Core 运行在 Linux/macOS 时，某些 Windows 特定的异常（如 COM 组件调用）可能不适用，需替换为跨平台方案或条件编译。

欢迎在评论区补充你的迁移经验，例如如何解决特定异常类型兼容性问题，或优化中间件性能的实践！

.NET Framework 实现方式

在 .NET Framework 中，全局异常处理通常通过自定义 HandleErrorAttribute 和全局过滤器实现。以下是实现步骤：

创建自定义异常处理特性类 CustomHandleErrorAttribute，继承自 HandleErrorAttribute：

public class CustomHandleErrorAttribute : HandleErrorAttribute
{
    public override void OnException(ExceptionContext filterContext)
    {
        if (filterContext.ExceptionHandled)
            return;
            
        var exception = filterContext.Exception;
        LogException(exception);
        
        if (filterContext.HttpContext.Request.IsAjaxRequest())
        {
            filterContext.Result = new JsonResult
            {
                Data = new { success = false, error = exception.Message },
                JsonRequestBehavior = JsonRequestBehavior.AllowGet
            };
        }
        else
        {
            filterContext.Result = new ViewResult
            {
                ViewName = "Error",
                ViewData = new ViewDataDictionary(exception)
            };
        }
        
        filterContext.ExceptionHandled = true;
    }
    
    private void LogException(Exception ex)
    {
        // 日志记录逻辑
    }
}

在 FilterConfig 类中注册全局过滤器：

public class FilterConfig
{
    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
    {
        filters.Add(new CustomHandleErrorAttribute());
    }
}

在 Global.asax 的 Application_Start 方法中调用过滤器注册：

protected void Application_Start()
{
    FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
}

.NET Core 实现方式

在 .NET Core 中，全局异常处理通常通过自定义中间件实现。以下是实现步骤：

创建异常处理中间件类 ExceptionMiddleware：

public class ExceptionMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<ExceptionMiddleware> _logger;

    public ExceptionMiddleware(RequestDelegate next, ILogger<ExceptionMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext httpContext)
    {
        try
        {
            await _next(httpContext);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "发生未处理的异常");
            await HandleExceptionAsync(httpContext, ex);
        }
    }

    private async Task HandleExceptionAsync(HttpContext context, Exception exception)
    {
        context.Response.ContentType = "application/json";
        context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;

        var response = new
        {
            statusCode = context.Response.StatusCode,
            message = "发生内部服务器错误",
            detailed = exception.Message
        };

        var options = new JsonSerializerOptions { PropertyNamingPolicy = JsonNamingPolicy.CamelCase };
        var json = JsonSerializer.Serialize(response, options);

        await context.Response.WriteAsync(json);
    }
}

在 Program.cs 中配置中间件：

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}
else
{
    app.UseMiddleware<ExceptionMiddleware>();
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Home}/{action=Index}/{id?}");

app.Run();

日志记录建议

在异常处理中，日志记录是重要环节。建议使用现有的日志框架：

在 .NET Framework 中使用 NLog：

private static readonly Logger Logger = LogManager.GetCurrentClassLogger();

private void LogException(Exception ex)
{
    Logger.Error(ex, "发生未处理的异常");
}

在 .NET Core 中使用内置的 ILogger：

_logger.LogError(ex, "发生未处理的异常");

生产环境注意事项

对于生产环境，应避免向客户端返回详细的异常信息。可以修改中间件以返回通用错误信息：

var response = new
{
    statusCode = context.Response.StatusCode,
    message = "发生内部服务器错误",
    detailed = app.Environment.IsDevelopment() ? exception.Message : null
};

2. 常见的 "坑" 及解决方案

坑 1：异常处理范围不完整

在.NET Core中，全局异常处理可以通过中间件实现，覆盖整个请求管道的异常，包括路由、身份验证等阶段。以下为具体方法：

自定义异常处理中间件

创建中间件捕获所有异常并统一处理：

public class ExceptionMiddleware
{
    private readonly RequestDelegate _next;
    public ExceptionMiddleware(RequestDelegate next) => _next = next;

    public async Task InvokeAsync(HttpContext context)
    {
        try { await _next(context); }
        catch (Exception ex)
        {
            context.Response.StatusCode = StatusCodes.Status500InternalServerError;
            await context.Response.WriteAsync("全局异常处理: " + ex.Message);
        }
    }
}

注册到Startup.cs：

app.UseMiddleware<ExceptionMiddleware>();

内置异常处理中间件

直接使用.NET Core提供的UseExceptionHandler：

app.UseExceptionHandler("/Error"); // 指定错误路由
app.UseStatusCodePagesWithReExecute("/Error/{0}"); // 处理404等状态码

对比旧版Framework方案

相比传统ASP.NET MVC的HandleErrorAttribute，中间件方案的优势在于：

• 可处理中间件管道中任何阶段的异常
• 能捕获静态文件处理、身份验证等非控制器逻辑的异常
• 支持自定义响应格式（JSON/HTML等）

进阶建议

• 生产环境区分开发/生产错误页（UseDeveloperExceptionPage）
• 结合日志系统（如Serilog）记录异常上下文
• 对API项目可返回标准化错误JSON格式

坑 2：开发 / 生产环境配置混淆

在开发环境中需要显示详细错误信息以便于调试，但在生产环境中需要隐藏这些信息以避免安全隐患。使用条件判断确保不同环境采用不同的异常处理策略。

if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}
else
{
    app.UseMiddleware<ExceptionMiddleware>();
    app.UseHsts();
}

坑 3：异常被多次处理

在 .NET Framework 中，同时使用 HandleErrorAttribute 和 Application_Error 事件可能导致异常被重复处理。应选择一种全局异常处理机制，并正确设置 ExceptionHandled = true 以避免重复处理。

坑 4：异步代码中的异常丢失

早期版本的 .NET Framework 在处理异步控制器方法时可能存在异常捕获不完整的问题。升级至最新版本或迁移到 .NET Core 可以解决这一问题，后者对异步代码的异常处理机制更加完善。

坑 5：日志记录不完整

仅记录异常消息而不记录堆栈跟踪或请求信息会导致调试困难。应采用完整的日志记录方式，包含异常对象、请求方法和路径等关键信息。

_logger.LogError(ex, 
    "异常发生在请求 {Method} {Path}", 
    context.Request.Method, 
    context.Request.Path);

3.讨论

迁移到 .NET Core 的异常处理挑战

从 .NET Framework 迁移到 .NET Core 时，异常处理机制的差异可能带来以下挑战：

HTTP 管道差异

在 .NET Framework 中，Global.asax 和 HttpApplication 的 Application_Error 是全局异常处理的主要方式。而 .NET Core 采用中间件（Middleware）模式，需使用 UseExceptionHandler 或自定义中间件捕获异常，迁移时需调整代码结构。

异步代码支持

.NET Core 更强调异步编程，未处理的异步异常可能导致进程崩溃。需确保 async/await 方法中异常被正确捕获，或通过 TaskScheduler.UnobservedTaskException 处理未观察的任务异常。

依赖注入集成

.NET Core 内置 DI 容器，异常处理中间件可能依赖注入的服务。需在中间件中正确解析服务，例如通过构造函数注入或 HttpContext.RequestServices。

日志记录变化

.NET Framework 中常用 System.Diagnostics.Trace 或第三方日志库，而 .NET Core 推荐使用 ILogger 接口。迁移时需重构日志记录逻辑，确保异常信息被正确输出到控制台、文件或第三方平台（如 Serilog）。

其他关键差异点

Kestrel 与 IIS 集成

.NET Core 默认使用 Kestrel 作为 Web 服务器，异常处理行为可能与 IIS 不同。例如，Kestrel 对请求超时或连接中断的响应方式需特别配置。

配置文件转换
web.config 被 appsettings.json 替代，异常处理相关的配置（如自定义错误页面路径）需迁移到新格式，并通过代码加载。

跨平台兼容性

.NET Core 运行在 Linux/macOS 时，某些 Windows 特定的异常（如 COM 组件调用）可能不适用，需替换为跨平台方案或条件编译。

欢迎在评论区补充你的迁移经验，例如如何解决特定异常类型兼容性问题，或优化中间件性能的实践！