业务规则违规是否会引发异常？

Question

业务规则违规是否会引发异常？

Answer 1

没有。它是程序中正常条件处理逻辑的一部分（通常只是伪装形式的用户错误）。

Answer 2

这取决于业务规则是什么，IMO。我冒昧地说“通常不会”，但我会根据具体情况来看待它。我不认为有任何一个答案，因为不同的业务规则可能会保证，而其他人可能不会。

Answer 3

首先，来自Jeffrey Richter的应用Microsoft .NET Framework编程（第402页）第18章的几个引用：

  

“另一个常见的误解是'例外'表示'错误'。”

     

“例外是违反程序界面的隐含假设。”

如果我从您的问题中正确推断出业务规则违规将超出某个范围（例如），那么这是一个错误，您可以使用@ahockley建议的条件来处理。根据Richter异常的定义，如果您的代码无法从您正在使用的任何存储库中检索业务规则，则适当使用异常。能够检索业务规则对于该接口具有合理的隐含假设，因此如果违反此假设则应抛出异常。

Richter的第一个引用（异常！=错误）的一个很好的例子是ThreadAbortException。如果调用Response.Redirect（url）（在ASP.NET中），即使重定向成功，也会抛出ThreadAbortException。为什么？ ASP.NET页面执行的隐含假设是页面将完全执行。 Response.Redirect（url）违反了这个假设，因此是例外。

Answer 4

由于我进行验证的方式以及我对ORM使用LINQtoSQL，是的。如果实体在OnValidate方法期间未能对业务规则进行验证，则通知调用代码的唯一方法是抛出异常。在这种情况下，我抛出一个自定义DataValidationException。在实体的部分类实现中使用OnValidate方法钩子使我可以在更新/插入时强制执行验证，因此只有有效数据才会保存到数据库中。

编辑我应该明确表示我通常会在客户端验证用户输入，因此持久层验证通常更加保险，而且很少（如果有的话）失败。我不将客户端验证作为异常处理，而是使用条件逻辑。

Answer 5

你的意思是，例如，一个值应该在0-99的范围内但不知何故最终是105？

如果它来自用户，则需要验证。是否使用异常处理取决于您的语言的习语。

如果它来自您的数据存储，那么是的，抛出异常似乎是合理的。这意味着你有糟糕的数据，你需要弄清楚它是如何到达那里并防止它再次发生的。

Answer 6

没有 违反业务规则是一个业务问题，例外是技术问题。违反业务规则是系统应该视为正常操作的事情，并且应该有一个程序化的响应，而不是例外。

Answer 7

作为大多数答案的替代视图......

从业务逻辑中抛出异常会很有用，特别是如果它们是由验证失败引起的。如果您期望一个对象并且您得到一个null，则表明某些问题已经避免在用户界面（或其他界面）中检测到。此时抛出异常可能完全有效。实际上，当有多个接口时，您可能决定将此类验证置于业务逻辑中。

在某些语言/框架中抛出异常（我认为是.NET）可能代价高昂，但这不应该立即让您担心。它的确意味着，顾名思义，它们用于特殊情况而不是程序标准流程的一部分。你当然不应该抛出一个异常只是为了退出一个方法。您还应该考虑在可能的情况下进行优雅恢复，但不包括抛出异常。

所以，总结......这取决于......

Answer 8

我会说不正常，但我认为你不能说永远不会。

例如，它取决于失败规则的处理对象/内容。如果它是用户界面/用户，那么我将使用条件逻辑来适当地处理故障。但是，如果业务规则失败，例如，一个不露面的进程将任何错误记录到事件日志中，该事件日志将由技术资源监视，那么异常可能是恰当的。在后一种情况下，适当命名的异常可以像格式良好的消息一样有用。

Answer 9

抛出异常可能是计算密集型的，它们超出常规范围。例如在.net中，你有增加的性能计数器 - 这是一个重量级的活动，所以不是你想做的事情，而不是简单的条件。

Answer 10

这实际上取决于它是什么以及它在哪里。

如果是来自用户的一些数据，那么levand表示这是一个验证问题。验证可以成功和失败，两者都是预期的选项，具有明确的进一步行动方案。

如果它类似于方法执行错误，那么抛出异常并在更多损害发生之前就停止（例如在数据库中产生不一致）可能是更好的主意。

这通常是透视和应用程序设计的问题。

Answer 11

Usualy我把条件放在一个实现

的Specification对象中

bool IsVerfiedBy(T entity);

所以你可以毫无例外地检查病情。

如果您的代码中有一个预先验证规范的地方，您可以抛出异常，因为这是您运作的先决条件。

例如，如果您的实体在持久化之前必须处于特定状态，则在未验证规范时抛出异常，但在持久化之前使用该规范，以便不会发生异常。

Answer 12

业务规则不应抛出异常，除非它们用于验证某些API的参数（即：检查请求有效性）或单元测试（即：using business rules to simplify .NET unit tests）。

通常，业务规则会向验证范围输出错误和警告消息。

Answer 13

业务规则可能会抛出异常但不应该抛出异常。

如果您有其他方式来传达有关常见和可预测验证错误的信息，则应使用它。

Answer 14

wiki for the book 每个项目经理应该知道的事情有很好的指导，特别是在Distinguish Business Exceptions from Technical一章中。

因此，如果您的编程语言支持它，最好的方法是创建自定义异常类，以便它们的工作流程和处理可能与技术异常不同。