C++ 错误处理 异常处理 RAII 是一种资源管理的技术 断言

C++ 错误处理

C++ 的错误处理确实是一个复杂且多面的议题，它涉及到性能、通用性、可靠性等多个方面的权衡。在 C++ 社区中，由于存在多种不同的解决方案和观点，很难找到一个能够满足所有人需求的终极方案。

C++ 提供了多种错误处理机制，包括但不限于异常处理、错误码、断言以及使用 RAII（资源获取即初始化）进行资源管理。每种机制都有其适用的场景和优缺点。

异常处理是 C++ 中处理错误的首选方式之一。它允许将错误信息从错误发生的位置传播到可以处理它的位置，从而提供了一种结构化的错误处理方式。然而，异常处理也带来了一定的性能开销，并且与析构函数的冲突可能导致程序行为不可预测。因此，在使用异常处理时，需要谨慎考虑其性能和可靠性影响。

错误码是另一种常见的错误处理方式。它通过返回特定的数字或符号常量来表示错误类型。错误码通常用于表示库或系统级别的错误，并且可以与返回值一起使用来提供详细的错误信息。然而，错误码的使用可能会增加代码的复杂性，并且需要程序员手动检查和处理每个可能的错误情况。

断言是一种用于验证假设条件的机制，如果条件不满足，则会引发异常。断言主要用于开发过程中的调试和验证，而不是用于生产环境的错误处理。

RAII 是一种资源管理的技术，通过在对象的构造函数中获取资源并在析构函数中释放资源，确保资源的正确获取和释放。这种技术可以有效地处理资源泄露问题，并在错误发生时保证资源的正确释放。然而，RAII 并不能直接处理逻辑错误或异常情况，而是更多地关注于资源的生命周期管理。

除了上述机制外，使用返回值和错误码也是一种常见的错误处理方式。通过返回值和错误码，程序员可以灵活地处理不同类型的错误，并在需要时提供详细的错误信息。然而，这种方式也可能导致代码冗长和难以维护。

在面对错误处理的问题时，我们应该根据具体的应用场景和需求来选择合适的机制。有时候，可能需要结合使用多种机制来达到最佳的效果。同时，我们也需要认识到没有一种解决方案是完美的，每种方案都有其局限性。因此，在选择错误处理方案时，我们需要权衡各种因素并做出折衷。

最后，尽管 C++ 社区中存在多种不同的观点和解决方案，但我们可以通过交流和讨论来增进彼此的理解并找到更好的解决方案。在错误处理这个领域，持续的学习和探索将有助于我们不断提高代码的质量和可靠性。

错误处理作为一种备受争议的话
题，我认为将长期存在下去。许多人在这个问题上有强烈的固有认知，其中一些是基于各种应用领域中扎实的经验——过去 50 多年已经有了很多相关的技术积累。在错误处理领域，性能、通用性、可靠性的需求往往发生冲突。

与 C++ 一样，问题不是我们没有解决方案，而是有太多解决方案。从根本上讲，很难通过单一的机制来满足 C++ 社区的多样化需求，但是人们往往只看到问题的一部分，就以为他们掌握了解决问题的终极方案 [Stroustrup 2019a]。

7.1 背景

C++ 从 C 语言中继承了各种基于错误返回码的机制，错误可以用特殊值、全局状态、局部状态和回调等多种方式表达。例如：

double sqrt(double d);  // 当 d 为负数时，设置 errno 为 33
int getchar();          // 遇到文件结尾返回 -1
char* malloc(int);      // 如果分配出错，返回 0

C++ 的早期用户（1980 年代）发现这些技术令人困惑，也不足以解决所有问题。返回 (值,错误码) 对变得流行，但这更增加了混乱和变化。例如：

Result r = make_window(arguments); // Result 是 (值,错误码) 对
if (r.error) {
   
    // ... 错误处理 ...
}
Shape* p = r.value;

繁琐的重复错误检查使代码变得混乱。使用错误码时，很难将程序的主要逻辑与错误处理区分开。程序的主线（业务逻辑）与大量奇怪和模糊的错误处理代码紧密耦合在一起。对于那些错误处理本身就是主要的复杂逻辑而言，这种基于错误返回码的处理方式可能会带来严重的问题。

使用包含 (值,错误码) 对的类会带来巨大的成本。除了检测错误码的成本外，许多 ABI（应用程序二进制接口）甚至不使用寄存器来传递小的结构体，所以 (值,错误码) 对不仅传递了更多的信息（是通常数量的两倍），而且也使传递的性能有数量级的降低。可悲的是，在许多 ABI 中，尤其那些针对嵌入式系统的 ABI（专为 C 代码设计），这个问题直到