在 Onion 架构中抛出异常与返回操作结果对象答案

【问题标题】：throwing exception vs returning operation result object in Onion architecture在 Onion 架构中抛出异常与返回操作结果对象
【发布时间】：2019-09-15 11:32:45
【问题描述】：

我有一个由 Onion Architecture 实现的项目，它类似于Ordering。我需要处理所有层中的验证错误。据我所知，通常有以下两种方法来处理错误：

1- 抛出异常

2-返回操作结果

在你看来，哪一个是最好的？

1- 抛出异常

这是我的方法。正如您在ValidatorBehavior 中看到的，我使用ValidatorBehavior 来处理与验证我的命令（如this）相关的验证错误。 FluentValidation 用于验证输入命令，错误缓存在ValidatorBehavior 的Handle 方法中。

其中一个问题是FluentValidation 如果命令无效则抛出异常。此异常可以缓存在 Web API 中的 HttpGlobalExceptionFilter 中。

有人说异常是针对意外情况，但在这个场景（验证）中，我们知道验证阶段的结果，我们通过抛出异常实现了一些业务规则。

另一个是在Domain Layer 中使用抛出异常，例如StatusChangeException。所以毫无疑问，我们需要在其他层抛出异常。

2-返回操作结果

在我的一些朋友建议的第二种方法中，我们可以使用句柄错误通过名为OperationResult 的对象向最终用户显示这些错误。从性能的角度来看，它似乎更好，因为抛出异常比第一种方法更昂贵。

您如何看待这两种方法？我想知道您是否分享您的想法以做出最佳决定。

【问题讨论】：

这取决于业务任务、特定项目、上下文、架构等。没有“经验法则”，但是在您选择了这些选项之一之后，最好坚持下去并完成所有错误以同样的方式处理。两者都有其优点和缺点。我个人更喜欢第二种方法

标签： c# error-handling architecture onion-architecture

【解决方案1】：

对于异常错误，我通常从所有层中抛出异常，这些异常在全局异常处理程序中处理。这允许我的应用程序和域代码保持“干净”，我的意思是，它可以专注于正常流程而不是处理异常。毕竟，异常是例外的，不是正常流程的一部分，所以对我来说，它们不应该拉扯你的“正常”逻辑。

至于您的性能评论，我认为这并不重要，因为您在这里谈论的是微优化，所以基本上，这不是一个真正的问题。

【讨论】：