C++核心准则E.25：如果不能抛出异常，模仿RAII方式进行资源管理-白红宇的个人博客

C++核心准则E.25：如果不能抛出异常，模仿RAII方式进行资源管理

发布日期：2021-07-01 05:29:25 浏览次数：2 分类：技术文章

本文共 4074 字，大约阅读时间需要 13 分钟。

E.25: If you can't throw exceptions, simulate RAII for resource management

E.25：如果不能抛出异常，模仿RAII方式进行资源管理

Reason（原因）

Even without exceptions, RAII is usually the best and most systematic way of dealing with resources.

即使不和异常一起使用，RAII通常是最好的，最系统化的处理资源的方式。

Note（注意）

Error handling using exceptions is the only complete and systematic way of handling non-local errors in C++. In particular, non-intrusively signaling failure to construct an object requires an exception. Signaling errors in a way that cannot be ignored requires exceptions. If you can't use exceptions, simulate their use as best you can.

使用异常的错误处理是C++中完全、系统化处理非局部错误的唯一方式。通常，非侵入式发出错误信号以便构造一个对象需要使用异常。以无法忽视的方式发出错误信号需要异常。如果你无法使用异常，尽你所能模拟它。

A lot of fear of exceptions is misguided. When used for exceptional circumstances in code that is not littered with pointers and complicated control structures, exception handling is almost always affordable (in time and space) and almost always leads to better code. This, of course, assumes a good implementation of the exception handling mechanisms, which is not available on all systems. There are also cases where the problems above do not apply, but exceptions cannot be used for other reasons. Some hard-real-time systems are an example: An operation has to be completed within a fixed time with an error or a correct answer. In the absence of appropriate time estimation tools, this is hard to guarantee for exceptions. Such systems (e.g. flight control software) typically also ban the use of dynamic (heap) memory.

很多关于异常的大量恐惧都是被误导的。当在没有被指针或复杂的控制结构搞乱的代码环境中使用异常时，异常处理几乎总是可以接受的（无论是时间还是空间维度），几乎总是可以带来更好的代码。当然，想象一个异常处理机制的良好实现，它不存在于任何系统。还是存在不属于上述问题，但由于其他原因而不能使用异常的情况。某些硬实时系统就是例子之一：一个操作必须在固定时间内完成并得到正确或错误的结果。如果没有适当的时间评价工具，异常很难满足这个要求。这样的系统（例如飞行控制系统）通常也会禁止使用动态（堆）内存。

So, the primary guideline for error handling is "use exceptions and RAII." This section deals with the cases where you either do not have an efficient implementation of exceptions, or have such a rat's nest of old-style code (e.g., lots of pointers, ill-defined ownership, and lots of unsystematic error handling based on tests of error codes) that it is infeasible to introduce simple and systematic exception handling.

Before condemning exceptions or complaining too much about their cost, consider examples of the use of error codes. Consider the cost and complexity of the use of error codes. If performance is your worry, measure.

因此，关于错误处理，主要的准则是“使用异常和RAII”。这个部分内容处理以下情况：要么你无法获得异常的高效实现，要么你的代码是老鼠窝一样的旧代码（例如，大量的指针，病态定义的所有权，大量的基于测试错误的非系统化错误处理），这时无法引入简单和系统化的异常处理。在谴责异常或抱怨异常的成本过高之前，考虑使用错误代码时的成本和复杂度。如果你担心性能，进行测量（而不是无根据的怀疑，译者注）。

Example（示例）

Assume you wanted to write

假设你想编写如下代码：

void func(zstring arg){    Gadget g {arg};    // ...}

If the gadget isn't correctly constructed, func exits with an exception. If we cannot throw an exception, we can simulate this RAII style of resource handling by adding a valid() member function to Gadget:

如果gadget无法正确构建，func会因为异常退出。如果你无法抛出异常，我们可以通过给Gadget增加一个valid成员函数来模拟RAII风格的资源管理。

error_indicator func(zstring arg){    Gadget g {arg};    if (!g.valid()) return gadget_construction_error;    // ...    return 0;   // zero indicates "good"}

The problem is of course that the caller now has to remember to test the return value.

这里的问题当然是调用者必须记得检查返回值。