language-agnostic - 先决条件和例外

Question

假设您有一个带有一些前置条件和后置条件的方法。是否可以为每个未完成的前置条件创建一个异常类？例如：不完成 pre1 意味着抛出一个 notPre1Exception 实例。

Answer 1

为什么不想定义 PreconditionFailedException(string precondition)？为每个失败的前提条件抛出不同的异常类型是矫枉过正的。

Answer 2

是和不是。

是的 - 违反先决条件当然是引发异常的合适时机。抛出更具体的异常将使捕获该特定异常更简单。

否 - 为您的程序/api 中的每个前提条件声明一个新的异常类似乎有点矫枉过正。这最终可能导致成百上千的异常。这在精神上和计算上似乎都是一种浪费。

我建议为违反前提条件抛出异常。但是，我不建议为每个前提条件定义一个新的例外。相反，我建议创建更广泛的异常类别，涵盖特定类型的前提条件违规，而不是特定的前提条件违规。（我还建议在它们适合的地方使用现有的例外。）

Answer 3

一个失败的前置条件应该抛出一个 AssertException 或类似的东西。在调用方法之前，它的前提条件必须成立。如果调用者没有做这个检查，那是程序中的一个错误，或者是方法（API）的错误使用。

Answer 4

只有在不满足前提条件的情况下才会发生罕见的异常情况。

Answer 5

听起来对我来说是一个有用的例外。它当然允许更细粒度的日志记录和调试，而不仅仅是一般的“前提条件失败”，尽管您也可以有一个“前提条件失败”异常并将哪些前提条件失败放入异常消息中。

Answer 6

我认为只要您计划使用和处理它们，就可以为所有异常创建不同的异常。

我发现错误/异常处理越好，在后期调试软件就越容易。

例如：如果您有一个通用的 excpeiton 来处理所有错误的输入，那么如果有错误，您必须查看传递给该方法的所有内容。如果您对所有类型的恶劣条件有一个 excpetion，您将知道在哪里寻找。

Answer 7

在我看来这是可能的，但如果你想继续这种处理前置条件的方式，你最终会得到每个类方法的 N 个异常类。看起来像“非功能”类的爆炸式增长。

我一直喜欢“核心”功能不处理违反先决条件的代码（除了断言它们 - 一个很大的帮助！）。然后可以将此代码包装在“前置条件检查器”中，它会抛出异常或通知不满足。

Answer 8

作为一种非常通用的方法来确定您是否应该创建一个类（并且异常是一个类），您应该确定是否有一些代码使这个类与所有其他类不同（在这种情况下是异常）。

如果没有，我只需将字符串设置在异常中并收工。如果你在你的异常中执行代码（也许是一个通用的恢复机制，可以通过调用 exception.resolve() 或其他东西来处理多种情况），那么它可能很有用。

我意识到异常并不总是遵循这条规则，但我认为这或多或少是因为语言提供的异常中不能有任何业务逻辑（因为他们不知道业务——库总是倾向于充满了 OO 规则的例外）

Answer 9

我认为本在这里是目标。如果您不打算捕获它们，那么抛出不同的异常有什么意义？如果你真的想抛出一个不同的，我至少会有一个共同的“PreconditionFailedException”基类，它们都派生自它们，并尝试将它们组织成某种层次结构，这样你就可以捕获它们的组。就个人而言，我不会有不同的，只是有一个常见的异常，你会抛出每个异常的失败细节。

Answer 10

不，您不应该为每个前提条件创建一个特定的例外，因为它会违反按合同设计的原则。

实现前置条件的必然结果是它们应该成为文档的一部分，并且您应该为调用者提供必要的方法来检查所有前置条件是否有效。（即，如果方法执行依赖于对象的状态，则检查状态的方法应该可供调用者使用）。

因此，调用者应该能够在调用您的方法之前检查是否满足所有先决条件。

为每个违反的先决条件实施特定异常将/可能鼓励调用者在方法调用周围使用 try/catch 模式，这与按合同设计的理念相矛盾。

Answer 11

我想说，只要你让它们成为未经检查的异常（Java 中 RuntimeException 的子类）就可以了。但是，在 Java 中最好只使用断言。

Answer 12

如果您这样做，请确保它们都继承自另一个常见的自定义异常。