Question

我们当前的许多控制器都是这样的：

[HttpPost]
public List<Foo> Post([FromBody]Bar model)
{
    if (model == null)
    {
        throw new ArgumentNullException();
    }

    try
    {
        // business logic
    }
    catch (Exception ex)
    {
        // logging
    }

    return dto;
}

虽然这里重复了很多代码。我想要做的是实现一个处理异常的基本控制器，这样我就可以使用Payload，Success，{{1}等字段返回标准化响应等等。

在.net核心之前，这可以通过提供Error的覆盖来实现，但是这似乎不适用于.net核心api控制器。如何在我的控制器体中出现问题时，如何合并此异常逻辑以返回自定义响应？

我喜欢这样，作为一个起点：

OnException

模型验证抛出的异常或[HttpPost] public StandardFoo Post([FromBody]Bar model) { if (model == null) { throw new ArgumentNullException(); } // business logic return new StandardFoo(){Payload: dto}; }冒泡到某个逻辑，该逻辑返回带有包含异常详细信息的属性的新business logic。

Answer 1

如果不久，您不应该在控制器中捕获和处理异常。

相反，您需要在代码中分离正常流和错误流，然后分别处理错误流。指示正常流程不可能的主要方法之一是引发.NET异常（并使用它）。但是：

控制器操作应该只知道正常流量。没有try-catch逻辑等等。
对于输入验证，请使用ActionFilter。您可能拥有所有控制器的全局过滤器或定义特定的每个操作。请参阅文档中的Filters section。 ASP.NET Core也允许执行Model Validation。
在控制器操作执行期间，您应该尽快引发异常并停止进一步的管道执行。是的，可以在任何级别（动作级别，服务/业务层，DA层等）上引发异常。

如何处理引发的异常呢？

由ASP.NET Core错误处理方法（如ExceptionHandler或Exception Filters）提供的使用，它允许分析异常并相应地生成适当/不同的响应。查看相关的SO Error handling in ASP.NET Core问题。文档中还有error-handling section。

Answer 2

我建议您创建自定义操作过滤器。这可以包含在WebApiConfig Register方法中的每个传入请求中（见下文）。

在我的例子中，我正在检查模型状态是否有效。

如果不是，我创建一个ErrorResponse并发回错误请求。

您不必简单地发回模型状态，如下例所示，您可以返回实际需要的任何内容。

这样，它在所有具有需要验证的模型的端点以及您想要在管道中进行的任何其他检查时变得一致。

注意：因为我们在全局注册此属性，所以我们不必在其他任何地方声明它，从此时起，所有传入的流量都要由此类检查。

string[] Line = sr.ReadLine().Split(',');
for (int i = 0; i < Line.Length ; i++)
{
    lines.Add(Line[i]);
    Row++;
}

使用ASP.net核心处理基本控制器中的异常（API控制器）

2 个答案: