冒着异常反模式的风险......进行一些修改

Question

假设我有一个在某些机器上 24x7 运行的库。即使代码坚如磐石，硬件故障迟早也会触发异常。我希望针对此类事件采取某种故障保护措施。一种方法是编写封装每个 api a 的包装函数：

returnCode=DEFAULT;
try
{
  returnCode=libraryAPI1();
 }
catch(...)
{
 returnCode=BAD;
}
return returnCode;

然后，库的调用者重新启动整个线程，如果 returnCode 错误，则重新初始化模块。

事情可能会变得非常糟糕。例如，

如果 try 块（或 libraryAPI1()）具有：

 func1();
 char *x=malloc(1000);
 func2();

如果 func2() 抛出异常，则 x 将永远不会被释放。同样，文件损坏也是一个可能的结果。

您能否告诉我在这种情况下还可能出现哪些其他问题？

Answer 1

硬件故障可能不会导致 C++ 异常。在某些系统上，硬件异常是与 C++ 异常完全不同的机制。在其他方面，C++ 异常构建在硬件异常机制之上。所以这实际上并不是一个一般的设计问题。

如果您希望能够恢复，则需要具有事务性——每个状态更改都需要运行完成或完全取消。 RAII 就是其中之一。正如克里斯·贝克在另一个答案中指出的那样，需要说明的不仅仅是资源获取。

有一种复制-修改-交换习惯用法在事务中被大量使用，但如果您尝试调整工作代码来处理这种百万分之一的情况，那么它可能太重了。

如果您确实需要鲁棒性，那么请将代码隔离到一个进程中。如果硬件故障终止了该进程，您可以让看门狗重新启动它。操作系统将回收丢失的资源。您的代码只需要担心持久状态的事务性，例如保存到文件中的内容。

Answer 2

您可以控制libraryAPI 的实现吗？

如果它适合OO模型，则需要使用RAII模式来设计它，这保证了析构函数（将释放所获取的资源）在异常时被调用。

使用资源管理助手（例如智能指针）也有帮助

try
{
    someNormalFunction();
    cSmartPtr<BYTE> pBuf = malloc(1000);
    someExceptionThrowingFunction();    
}
catch(...)
{
    // Do logging and other necessary actions
    // but no cleaning required for <pBuf>
}

Answer 3

例外的问题是 - 即使您使用 RAiI 进行重新设计 - 它仍然很容易使代码变得不同步：

void SomeClass::SomeMethod()
{
  this->stateA++;
  SomeOtherMethod();
  this->stateB++;
}

现在，该示例可能看起来很人为，但如果您用 stateA++ 和 stateB++ 代替操作以某种方式改变类的状态，此类的预期结果是状态保持同步。 RAII 可能会解决使用异常时与状态相关的一些问题，但它所做的只是提供一种错误的安全感 - 如果 SomeOtherMethod() 抛出异常，则需要分析所有周围的代码以确保后置条件 (stateA. delta == stateB.delta) 得到满足。

Answer 4

此代码：

func1();
char *x=malloc(1000);
func2();

不是 C++ 代码。这就是人们所说的带有类的C。它是一种看起来像 C++ 的程序风格，但与现实生活中 C++ 的使用方式并不相符。原因是；良好的异常安全 C++ 代码实际上从不需要在代码中（直接）使用指针，因为指针始终包含在专门设计用于在异常安全庄园（通常是智能指针或容器）中管理其生命周期的类中。

该代码的 C++ 等效项是：

func1();
std::vector<char> x(1000);
func2();