何时对域类中的异常使用断言答案

【问题标题】：When to use assertion over exceptions in domain classes何时对域类中的异常使用断言
【发布时间】：2009-01-05 19:20:24
【问题描述】：

在任何情况下，您会在域类中使用断言而不是异常处理...

【问题讨论】：

标签： exception exception-handling error-handling

【解决方案1】：

使用异常进行参数验证和其他检查，以验证您的类的用户是否按预期使用它们。

使用断言进行内部一致性检查，即表明你搞砸了，而不是你班级的用户。

因此，如果您的类的用户看到断言失败，他们知道这（可能）是您的代码中的内部错误，而不是他们使用您的代码的错误。另一方面，如果get参数验证异常，他们就知道是他们的错。

【讨论】：

【解决方案2】：

从来没有。断言不是错误处理的有效形式。在测试期间使用它们来帮助识别程序错误。

【讨论】：

【解决方案3】：

一个断言反映了一种不应该发生和不期望的状态，其中应用程序由于某种原因无法继续执行，而异常表示一种不被认为是“正常”但并非意外的状态，并且有可能从中恢复。

举个例子，如果我在堆上分配空间，而这个分配失败，那么我就不能继续工作，所以我断言返回的地址是有效的；在它无效的地方，断言失败，程序也随之失败。

另一方面，如果我打开一个文件进行读取，但它不存在，那么可能会从这种情况中恢复，在这种情况下会抛出异常（并捕获并处理至可能）。

通常，断言在调试阶段最有用，而异常则被视为常规程序流程和错误处理的一部分。普遍的共识是，应该在生产代码中禁用断言（以保护用户免受明显的崩溃），而我读过一个学派认为这是适得其反的，并且用户应该看到断言失败，以便他们可以正确报告问题。

就个人而言，我有时会将这两种技术结合起来；通常，如果我发现了一个我认为不会被抛出的异常。以上面的例子为例，如果我在尝试打开文件之前检查文件是否存在，那么我不希望抛出异常，如果是，那么我倾向于通过在相关的 catch 块中提出断言来处理这个问题。我发现这是一种在 Java 中特别有用的技术，在这种技术中，此类异常会得到全面检查。

【讨论】：