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

解决方案

只有不满足准备工作，这种情况才会罕见。

在我看来，这是对异常的有用用法。尽管我们还可以有一个"前提条件失败"异常，并将哪些前提条件失败放入异常消息中，但是它肯定比一般的"前提条件失败"允许更细粒度的日志记录和调试。

我们为什么不想要定义PreconditionFailedException(string precondition)？为每个失败的前提条件抛出不同的异常类型是过大的杀伤力。

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

我发现错误/异常处理越好，在以后的阶段中调试软件就越容易。

例如：如果我们有处理所有错误输入的通用实例，那么在出现错误的情况下，我们必须查看传递给方法的所有内容。如果我们对所有类型的恶劣条件都情有独钟，那么我们会发现哪里有问题。

在我看来，这是可能的，但是如果我们想继续这种处理前提条件的方法，则每个类方法最终将获得N个异常类。看起来像"非功能"类的爆炸式增长。

我一直喜欢"核心"功能不能处理违反准备工作的代码(除了断言它们有很大帮助！)。然后可以将此代码包装在"前提条件检查器"中，该检查器确实会引发异常或者以其他方式通知不满意情况。

作为确定是否应该创建一个类(异常是一个类)的一种非常通用的方法，我们应该确定是否存在使该类与所有其他类不同的代码(在本例中为异常)。

如果没有，我将在异常中设置字符串，然后将其命名为" day"。如果我们在异常中执行代码(也许是一种通用的恢复机制，可以通过调用exception.resolve()或者其他方法来处理多种情况)，那么它可能会很有用。

我意识到异常并不总是遵循此规则，但我认为这或者多或者少是因为语言提供的异常中不能包含任何业务逻辑(因为它们不了解业务，所以图书馆总是倾向于OO规则的例外情况)

失败的前提条件应引发AssertException或者类似的东西。在调用方法之前，必须满足准备工作。如果调用者不执行此检查，则是程序中的错误或者方法(API)的错误使用。

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

是的，没有。

是违反准备工作当然是引发异常的适当时间。引发更具体的异常将使捕获该特定异常更加容易。

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

我建议对前置条件违反抛出异常。但是，我不建议为每个前提条件定义一个新的例外。相反，我建议创建更广泛的例外类别，以涵盖特定类型的准备工作违规，而不是特定的准备工作违规。 (我还建议在适合的情况下使用现有的例外。)

我认为Ben在这里很准。如果我们不打算捕获它们，那么抛出不同的异常又有什么意义呢？如果我们真的想抛出一个不同的类，那么我至少将有一个通用的" PreconditionFailedException"基类，它们都派生自该基类，并尝试将它们组织成某种杂乱无章的样式，以便可以捕获它们的组。就个人而言，我不会有不同的看法，只是我们会抛出一个常见的异常，每个异常中都包含失败的详细信息。

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

不，我们不应该为每个前提创建特定的例外，因为这将违反按合同设计的原则。

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

因此，调用者应该能够在调用方法之前检查是否满足所有准备工作。

为每个违反的前提条件实现特定的异常会/将鼓励调用者在方法调用周围使用try / catch模式，这与按合同设计的理念背道而驰。