return Problem(errorMessage) 是在 asp.net 核心中返回任何类型错误的正确方法吗？答案

【问题标题】：is return Problem(errorMessage) is the right way to return any kind of error in asp.net core?return Problem(errorMessage) 是在 asp.net 核心中返回任何类型错误的正确方法吗？
【发布时间】：2022-02-17 15:22:35
【问题描述】：

我是 Asp.net 核心 Web API 的新手。

如果我们不确定特定的状态码，返回 Problem(errorMessage) 是在 asp.net 核心中返回任何类型错误的正确方法。

下面是我的代码，

        [HttpPost]
        public async Task<ActionResult> Post([FromForm] MyModel request)
        {
            var (success,statuscode, errorMessage) = await _service.MyMethod(Id, request);
            return success ? Ok() : Problem(errorMessage, statusCode: statuscode);
        }

如果出现任何错误，MyMethod 方法将返回 BadRequest 或 UnprocessableEntity 状态代码。

那么，在 Problem() 中返回错误是否正确？

提前致谢！

【问题讨论】：

您的服务不应直接与 HTTP 状态代码耦合。我通常会制作服务可以抛出的自定义异常，并添加一个全局过滤器，可以将这些异常转换为适当的 HTTP 响应。这样你就不必为每个操作添加相同的错误处理代码

标签： c# rest asp.net-core asp.net-core-webapi

【解决方案1】：

对于任何验证问题，如果您想按书阅读并在 ProblemDetails 中添加详细信息，则应返回 422 的 UnprocessableEntity（请查看下方）。现在，这不是强制性的。归根结底，您的 api 是您与客户之间的合同，您应该为集成定义此手动检查。您在服务器端期望什么以及客户端将收到什么。现在，对于全局异常，您可以注入一个中间件并捕获它们并提供所发生情况的指定详细信息。在这种情况下，您应该返回一个 ProblemDetails 实例。

ProblemDetails class

ietf 试图通过指定此类的详细信息来创建标准。

现在默认情况下，当您返回此类型时，您还应该包含 MediaType，如果请求是 get，您应该作为标头的一部分返回 Accept: application/problem + json 使用帖子，您将添加 Content-Type:application/problem + json。

我的建议：现在对于验证问题，您可以检查 ModelState.IsValid ，如果您的模型有任何错误，它应该在 Errors 属性上。对于例外情况，请使用中间件。

现在这不是蓝图。您可以扩展课程，或者客户可以使用其他类型的格式来处理您的回复，以防出现任何错误，正如我所说，这是您和您的客户之间的合同。

【讨论】：