提问人：Joris Mathijssen 提问时间：12/6/2021 最后编辑：Guru StronJoris Mathijssen 更新时间：12/6/2021 访问量：921
.NET 5 - 正确处理 Web API 中的预期 404 或 400 错误.NET 5 - Correctly handling expected 404 or 400 errors in a web API
.NET 5 - Correctly handling expected 404 or 400 errors in a web API
问：
我正在寻找一种正确的方法来处理我的 Web API 中的预期错误。
例如，我有一个具有 2 个可能响应的端点。
- 200 正常，带有结果对象
- 404 Not Found，带有一个 ApiError 对象，包含一个小的（本地化）消息和标题。
目前，我在代码中我知道资源是否正常或未找到的位置抛出一个自定义异常。我有一个自定义中间件来捕获这些异常并创建一个格式化的 ApiError。
这很完美，除了所有这些（已知）消息也记录在我的日志文件/Application Insights 中。向此异常添加一个布尔值感觉很奇怪，我可以指定是否应该记录异常。但目前，这似乎是唯一可行的方法。
是否有任何建议可以使此实现更加可靠，或者我应该更改实现？
答：
2赞
TomTom
12/6/2021
#1
好吧，问题不在于 .NET 5，而在于应用程序洞察力。
你的中间件基本上应该告诉AI，这些特定的错误不是错误。
基本上，从 ApplicationInsight 获取 ITelemetryInterface，并告知尽管有错误代码，但请求是成功的。
瞧，问题解决了。AI 无法神奇地知道特定的 404 错误是“预期”的正常操作 - 您将不得不帮助它。
在网站/Web 应用程序级别跟踪它们是有意义的。将它们视为后端级别的错误是没有意义的。从 API 的角度来看，响应（未找到）是完全有效的。只需相应地配置 AI。
评论
0赞
Joris Mathijssen
12/6/2021
我同意这确实是问题所在。我将添加过滤。因此，抛出自定义异常并在中间件中处理它们的想法是正确的。我有时也会有一个糟糕的请求响应。例如，如果用户发布尚不可能的对象。这应该由引发的异常处理吗？
0赞
TomTom
12/6/2021
是的。鉴于“正常”流程是返回对象，因此没有其他选择。因此，异常/中间件方法。
评论
NotFoundResult。