FastEndpoints框架中自定义错误响应的正确实践

在FastEndpoints框架的使用过程中，开发者可能会遇到错误消息格式不符合预期的问题。本文将通过一个典型案例，深入分析错误消息处理的机制，并提供最佳实践方案。

问题现象

当开发者使用ThrowError()方法抛出异常时，前端接收到的错误消息会包含"ThrowError() called - "这样的前缀。类似地，使用Validator<>进行参数验证时，默认会带有"Request validation failed..."的前缀信息。

原因分析

FastEndpoints框架的错误处理机制包含两个关键部分：

1. 自动错误转换：框架内置的Errors.ResponseBuilder负责将4XX级别的验证错误自动转换为JSON格式的错误响应
2. 异常处理中间件：用于捕获和处理5XX级别的未处理异常

当开发者同时使用UseExceptionHandler自定义错误响应，又调用DontCatchExceptions()方法时，会破坏框架默认的错误处理流程，导致原始异常信息直接暴露给客户端。

解决方案

要实现统一且符合预期的错误响应，建议采用以下方案：

1. 保留框架默认的错误处理：不要轻易使用DontCatchExceptions()方法
2. 统一配置错误响应：通过c.Errors.ResponseBuilder自定义4XX错误的响应格式
3. 分离异常处理：使用UseExceptionHandler仅处理5XX级别的系统异常

最佳实践

// 配置FastEndpoints错误响应
app.UseFastEndpoints(c => {
    c.Errors.ResponseBuilder = (failures, ctx, statusCode) => {
        return new {
            Code = statusCode,
            Errors = failures.Select(f => new {
                Field = f.PropertyName,
                Message = f.ErrorMessage
            })
        };
    };
});

// 配置全局异常处理
app.UseExceptionHandler(exceptionHandlerApp => {
    exceptionHandlerApp.Run(async context => {
        // 仅处理5XX错误
        context.Response.StatusCode = StatusCodes.Status500InternalServerError;
        await context.Response.WriteAsJsonAsync(new {
            Code = 500,
            Message = "系统内部错误"
        });
    });
});

总结

FastEndpoints框架提供了完善的错误处理机制，开发者应充分理解其设计理念：

1. 4XX错误由框架自动处理，通过ResponseBuilder统一格式
2. 5XX错误通过中间件处理，不应暴露系统细节
3. 避免混用自定义异常处理和框架默认机制

通过合理配置，开发者可以既保持错误响应的统一性，又能满足各种业务场景的需求。