如何创建和执行例外合同？

我试图说服我的团队领导者允许在C ++中使用异常，而不是返回isSuccessful带有错误代码的布尔值或枚举。但是，我不能反驳他的批评。

考虑这个库：

class OpenFileException() : public std::runtime_error {
}

void B();
void C();

/** Does blah and blah. */
void B() {
    // The developer of B() either forgot to handle C()'s exception or
    // chooses not to handle it and let it go up the stack.
    C();
};

/** Does blah blah.
 *
 * @raise OpenFileException When we failed to open the file. */
void C() {
    throw new OpenFileException();
};

1. 考虑开发人员调用该B()函数。他检查了它的文档，发现它没有返回异常，因此他没有尝试捕获任何东西。此代码可能会使程序在生产中崩溃。

2. 考虑开发人员调用该C()函数。他不检查文档，因此不捕获任何异常。该调用不安全，可能会使程序在生产中崩溃。

但是，如果我们以这种方式检查错误：

void old_C(myenum &return_code);

如果使用该函数的开发人员不提供该参数，则会被编译器警告，并且他会说“啊哈，这将返回我必须检查的错误代码”。

如何安全使用异常，以便达成某种合同？

这是对例外的合理批评。 与简单的错误处理（例如返回代码）相比，它们通常不那么可见。而且没有简单的方法可以执行“合同”。这样做的部分目的是使您能够在更高级别上捕获异常（如果必须在每个级别上捕获每个异常，无论如何与返回错误代码有何不同？）。这意味着您的代码可能会被其他无法正确处理的代码调用。

例外确实有缺点。您必须根据成本效益提出理由。
我发现这两篇文章对您有所帮助：例外的必要性和例外。 此外，此博客文章还提供了许多专家对异常的意见，重点是C ++。尽管专家的意见似乎倾向于例外，但远未达成明确的共识。

至于说服您的团队领导，这可能不是正确的选择。尤其是没有旧版代码。如以上第二个链接所述：

异常不能通过任何不安全的代码传播。因此，使用异常意味着项目中的所有代码都必须是异常安全的。

向主要不使用异常的项目中添加少量使用异常的代码可能不会有所改善。在编写良好的代码中不使用异常远不是灾难性的问题。可能根本不是问题，这取决于应用程序和您要求的专家。你必须选择自己的战斗。

这可能不是我要花力气的一个论点-至少要等到一个新项目开始时，我才开始努力。即使您有一个新项目，它也将被任何旧代码使用还是被其遗留代码使用？

从字面上看，有整本书都写在这个主题上，所以任何答案都只能是总结。根据您的问题，以下是我认为值得提出的一些重要观点。这不是一个详尽的清单。

不应在所有地方都捕获异常。

只要在主循环中有一个通用的异常处理程序-根据应用程序的类型（Web服务器，本地服务，命令行实用程序...）-通常，您将拥有所需的所有异常处理程序。

在我的代码中，在主循环之外只有几个catch语句-如果有的话。这似乎是现代C ++中的常用方法。

异常和返回码不是互斥的。

您不应该将其作为一种全有或全无的方法。在特殊情况下应使用例外。诸如“找不到配置文件”，“磁盘已满”或其他无法在本地处理的内容。

常见的失败（例如检查用户提供的文件名是否有效）不是异常的用例；在这些情况下，请使用返回值。

从上面的示例中可以看到，根据使用情况，“找不到文件”可以是异常，也可以是返回码：“是安装的一部分”与“用户可以打错字”。

因此，没有绝对的规则。一个粗略的指导原则是：如果可以在本地处理，则使其成为返回值；如果您无法在本地处理它，则引发异常。

静态检查异常没有用。

由于无论如何都不应在本地处理异常，因此通常可以抛出哪些异常并不重要。唯一有用的信息是是否可以引发任何异常。

Java具有静态检查功能，但是它通常被认为是失败的实验，并且大多数语言（尤其是C＃）由于没有这种类型的静态检查。这是有关C＃没有它的原因的很好的阅读。

由于这些原因，C ++已经过时了throw(exceptionA, exceptionB)赞成noexcept(true)。默认值是函数可以抛出的值，因此，除非文档中明确声明，否则程序员应该期望这样做。

编写异常安全代码与编写异常处理程序无关。

我想说的是，编写异常安全代码就是如何避免编写异常处理程序！

大多数最佳实践旨在减少异常处理程序的数量。一次编写代码并自动调用它（例如通过RAII）比在整个地方复制粘贴相同的代码所导致的错误更少。

C ++程序员不寻找异常规范。他们寻找例外保证。

假设一段代码确实引发了异常。程序员可以做出哪些假设仍然有效？从编写代码的方式来看，代码在发生异常之后能保证什么？

还是某个代码段可以保证永远不会抛出该异常（即，除了OS进程被终止外）？

“回滚”一词在有关异常的讨论中经常出现。能够回滚到有效状态（已明确记录）的方法是异常保证的一个示例。如果没有例外保证，则程序应当场终止，因为甚至不能保证程序之后执行的任何代码都能按预期运行-例如，如果内存已损坏，则任何进一步的操作在技术上都是未定义的行为。

各种C ++编程技术可促进异常保证。RAII（基于范围的资源管理）提供了一种执行清除代码并确保在正常情况下和例外情况下都释放资源的机制。如果对对象执行修改，则在进行数据复制之前，如果操作失败，则可以恢复该对象的状态。等等。

这个StackOverflow问题的答案使人一窥C ++程序员去了解代码可能发生的所有可能的失败模式，并尽力保护程序状态的有效性，即使失败了。C ++代码的逐行分析成为一种习惯。

当使用C ++开发（用于生产用途）时，人们无法掩饰细节。同样，二进制Blob（非开源）是C ++程序员的祸根。如果我必须调用某个二进制Blob，但该Blob失败，则C ++程序员接下来将要做反向工程。

参考：http : //en.cppreference.com/w/cpp/language/exceptions#Exception_safety-请参阅“异常安全性”下的内容。

C ++在实现异常规范方面尝试失败。后来用其他语言进行的分析表明，异常规范根本不切实际。

为什么尝试失败：严格执行它，它必须是类型系统的一部分。但事实并非如此。编译器不检查异常规范。

为什么C ++选择了它，以及为什么其他语言（Java）的经验证明了异常规范尚无定论：当修改一个函数的实现时（例如，它需要调用另一个函数，这可能会引发一种新的异常）。例外），严格的例外规范执行意味着您还必须更新该规范。这会传播-您可能最终不得不为一个简单的更改而更新数十个或数百个功能的异常规范。对于抽象基类（相当于C ++的接口），情况会变得更糟。如果在接口上强制执行异常规范，则不允许接口的实现调用引发不同类型异常的函数。

参考：http : //www.gotw.ca/publications/mill22.htm

从C ++ 17开始，[[nodiscard]]可以在函数返回值上使用该属性（请参阅：https : //stackoverflow.com/questions/39327028/can-ac-function-be-declared-such-that-the-return-value -不能被忽略）。

因此，如果我进行代码更改，并且引入了一种新的失败条件（即，一种新的异常类型），这是否是一项重大更改？是应该迫使调用者更新代码，还是至少应警告更改？

如果您接受C ++程序员寻找异常保证而不是异常规范的论点，那么答案是，如果新的故障条件没有破坏代码先前承诺的任何异常保证，那不是一个重大改变。

考虑开发人员调用C（）函数。他不检查文档，因此不捕获任何异常。通话不安全

完全安全。他不需要在每个地方都捕获异常，他可以在一个实际可以做一些有用的事情的地方抛出一个try / catch。如果他允许它泄漏出线程，这是不安全的，但是通常很难防止这种情况的发生。

如果要构建关键系统，请考虑遵循团队负责人的建议，不要使用异常。这是洛克希德·马丁公司联合打击战斗机C ++编码标准中的 AV规则208 。另一方面，MISRA C ++准则具有非常特殊的规则，涉及在构建符合MISRA的软件系统时何时可以使用例外以及何时不能使用例外。

如果要构建关键系统，则可能还会运行静态分析工具。如果您不检查方法的返回值，许多静态分析工具都会发出警告，从而使遗漏错误处理的情况显而易见。据我所知，用于检测正确的异常处理的类似工具支持并不那么强大。

归根结底，我认为通过合同和防御性编程进行设计以及静态分析对于关键软件系统来说比异常情况更安全。